Re: Hmmmm.

Hi All,

        I've heavily modified our squid here to have most of the following
features. Duane has the code/patches already but it's an issue on how to
integrate these patches into the current release given that some calling
conventions needed to be changed to support callbacks...

> Yes, kicking it around last night that was one idea we came up
> with. Some other as food for discussion.
>
> #1. Something that's dead easy to do that'll give an immediate 20%
> improvement on our box is to has a seperate process doing the
> unlink()'s. i.e. spawn off
> perl -nle unlink
> and write the name of the files to the process instead of trying to do
> it in squid. Nice and easy to do.

        I've implemented an async() library under which it's very easy to
attach any number of system calls which will happen via threads (much faster
than inter-process communication). unlink() was separated as one of the
first things to do. The cache now no longer slows down when the high-water
mark is hit on cache_swap. Further, mass deletions now happen about 5 times
faster. The async() library uses POSIX threads at the simplest level which
is easily portable to the majority of other OS's thread implementations.

> #3. A seperate process doing all the disk I/O. Send commands for
> read/writes to it. Means that you'll never block for disk I/O in the
> server.
>
> Problem is that it'll be a bloody mess to write!
>
> You could start off just handling reads that way. but either way,
> messy.

        open(), read(), write(), close(), stat(), opendir() and readdir() were
all threaded. These calls all now take (effectively to the squid parent
process) the time to create a thread to complete, which is about .0002s on
solaris. Squid now flies, with no I/O blocking at all. Squid's internal code
had to be rather heavily modified to support the notion of callbacks when
each call had completed. This was about 2 weeks work to write and debug.
Again, all the patches are with Duane already. Our squid server runs about
10+ times faster than any other squid server you care to compare with under
heavy loads.

> #4. as mentioned above. mmap() to share memory. child processes all
> parent via parent process, children never write to MMAP, only
> read. Means that you should be able to get away without locking if the
> parent ensures that it never updates in the wrong order. Children
> never write objects to disk, only read cache hits, and proxy-only
> requests.
>
> This is only useful on machines getting a fairly high cache hit ratio,
> or machines that have lots of things they proxy-only for.

        Squid really needs to be written to be completely multi-threaded.
When a request comes in, a thread should be forked which deals with that
request alone, and everyone's happy. This would simplify squid substantially
as long as the critical sections were separated distinctly into separate
modules. You don't even require shared memory (since threads all share the
same process's memory anyway). This would be a major rewrite, and if DEAD
SIMPLE thread conventions were used, it should be fairly portable (thr_create,
thr_join about the only two thread calls used).

> The best and the hardest is the seperate daemon doing disk. The one
> that can easily be done right now is unlink as a seperate process.

        I actually implemented this initially, but it has the overhead of yet
another process and yet another context switch, and unlink()s still only
happen sequentially, whereas when issuing unlink()s via threads, you can have
many outstanding and the OS can optimise its disk head scan algorithm to full
effect, so there is much better utilisation of the disks.

> Michael, kicking ideas safe in the knowledge that he doesn't have time
> to do any of them. :(

        I've done them. I'll be happy to redo a threaded squid in my spare
time given some discussion/co-ordination with Duane. Anthony Baxter here
at Connect has also played around with writing a Python based threaded
mini-squid, so if people are wanting and we aren't clashing with the main
development tree, we'll be happy to give it a bash.

        Cheers,

                Stew.

-- 
Stewart Forster (Security and Web Proxy Cache Administrator)
connect.com.au pty ltd, Level 9, 114 Albert Rd, Sth Melbourne, VIC 3205, Aust.
Email: slf@connect.com.au   Phone: +61 3 9251-3684   Fax: +61 3 9251-3666