On Fri, Mar 07, 2008, Mark Nottingham wrote:
> Ideally, you'd avoid locking as much as possible; e.g., have a pool of
> threads for disk access (as now with aufs), a pool for header parsing,
> a pool for forward requests, and so on. I don't think it's a good idea
> at all to re-architect squid into a thread-per-connection model or
> anything; just find the places that are bottlenecks and allow some
> parallelism, keeping the number of threads low.
Oh I wouldn't do thread-per-connection, thats a silly idea.
> (says he, the non-threads programmer. I'm not *that* crazy...)
>
> Redirectors and other helpers are already able to run on other CPUs,
> so that's a non-issue.
Yes, but a lot of the redirector stuff could be done mostly in-line using some
threads and cheap IPC, rather than processes and (potentially comparitively
expensive[1]) IPC.
Then you can do things like eCAP type modification inline using threads with
data being passed around in larger chunks/chains without copying.
I'd follow with more conjecture but right now I need to gather some more
data, do paid work to start raising money to fund further Squid improvements,
and pass my units. Conjecture has to wait. :)
Adrian
[1] some OSes (eg FreeBSD) do make a point of doing page-wiring tricks when
doing inter-process socket stuff (thus avoiding copies), but its tricky
to get right[2]
[2] And from my own fiddling, its not worth trying to get right until you're
doing a _LOT_ of IPC; and even then the biggest thing to try and do is avoid
stupidly high numbers of syscalls (eg one per request) when you could probably
buffer a whole lot of stuff and issue one big write() ..
--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
