Re: [squid-users] Squid-2, Squid-3, roadmap

Well, the way I'd approach it is to first get an idea of how to throw
things into 'threads', and probably draft and craft a basic event loop
and submission queue for "stuff" to happen across threads.

Then "Squid" can run as one thread, and CPU intensive stuff can happen
via message queues to other threads.

Eventually my gut feeling (reliable as it is) tells me that the most
efficient and scalable way of doing this is to create a lightweight
"squid" that handles just client and server-side interactions, with storage,
logging, ACLs and other stuff happening in other threads, and then
create multiple "squid" threads that run almost indepedently from one another.
This would avoid all of the crazy fine-grain locking that traditionally is done
to take a non-threaded app into the threaded world. I really think
avoiding that is a very good idea.

Oh, and no, there's nothing in Squid right now that "jumps out" save perhaps
pushing regular expression lookups into a seperate thread or threads. But
really, if you're going to do that then you're better off pushing a large part
of the ACL subsystem into seperate threads and have the main code submit
lookup requests there. Of course, what would be interesting there is benchmarking
how effective it'd be to batch things like ACL lookups in "groups" to try and
get some cache coherency effects going, rather than the current tendency for Squid
to process a request as far as it can go before something blocking comes along,
blowing much of the CPU cache away as possible in the meantime.

But really, the big problem is to spend some time looking at efficient
ways of parallelising network applications and what works well on current
hardware/OSes. I'm just playing around with a simple TCP proxy right now which
I'll use to experiment with "better" ways of doing stuff reasonably portably.
I can then set this as the "upper bounds" for how well stuff may perform, and
can then spend some time looking at how to tune things like parallelism,
IO handling, memory allocation and event notification. Then I can spend some more
time looking at batching operations such as IO, ACL lookups, etc - see if better
use of CPU caches can be made and also see if doing all the system read/write
syscalls in one hit per loop rather than spread out throughout the program execution
makes any difference.

Its really hard to benchmark -these- inside Squid, and thus its very difficult to
figure out how to make better use of current hardware. _This_ is the "First Problem"
to solve.

Of course, all of this depends entirely on whether I get enough clients to start
funding some of this work, and how much I can dedicate to this over my Semantics,
Experimental Methods and Behavioural Neuropsychology classes this semester. :)

Adrian
(Sleep? Hah!)

On Thu, Mar 06, 2008, Chris Woodfield wrote:
> I'll readily admit that I Am Not A Developer, but I'm wondering if
> this could be something that could be worked incrementally - finding
> easy-to-cleave-off subsystems that can be moved to separate threads
> similarly to how asyncio was. The most obvious one I can think of is
> the front-end client/server network socket communication code; next
> would be logging. Are there any other subsystems that jump out as
> "independent" enough to do this in the existing code base?
>
> -C
>
> On Mar 6, 2008, at 4:17 AM, Adrian Chadd wrote:
>
> >On Wed, Mar 05, 2008, Michael Puckett wrote:
> >>Mark Nottingham wrote:
> >>>
> >>>A killer app for -3 would be multi-core support (and the perf
> >>>advantages that it would bring), or something else that the
> >>>re-architecture makes possible that isn't easy in -2. AIUI, though,
> >>>that isn't the case; i.e., -3 doesn't make this significantly
> >>>easier.
> >>Absolutely THE killer app for either -2 or -3. The fact that multi-
> >>core
> >>processors are now the defacto standard in any box makes this more
> >>important by the day IMHO. Being able to do sustained IO across
> >>multiple
> >>Gb NICs will absolutely require it. This is the single biggest
> >>performance enhancement that could be implemented. So where does
> >>multi-core support fall on either roadmap?
> >
> >12 months away on my draft Squid-2 roadmap, if there was enough
> >commercial
> >interest. Thing is, the Squid internals are very horrible for SMP
> >(both 2 and 3)
> >and the list of stuff that I've put into the squid-2 roadmap is what
> >I think
> >is the minimum amount of work required before really starting to
> >take advantage
> >of multiple cores.
> >
> >
> >
> >
> >Adrian
> >
> >--
> >- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial
> >Squid Support -
> >- $25/pm entry-level VPSes w/ capped bandwidth charges available in
> >WA -
> >

-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -