Squid performance wish-list

Hiya,

        Want to open a forum for possible performance enhancements to squid.
Other than hard-slogging of hand optimising the various algorithms in squid
which would gain probably 10% with LOTS of work, I'm suggesting the following
big-feature speed gains:

Things that would work well/worth investigating:

*) Priority queues in select() loop:

From the way I look at it, there are many different kinds of sockets:

HTTP receive - Already handled specially
ICP receive - Already handled specially

Active client connections - connections where we are expecting to receive
a request on, or send data down.

Idle client connections - connections that are waiting for some data to
come back from a server

Persistent idle client connections - connections we don't expect to see
a request on immediately

Active server connections - connections we are about to send a request down
or are expecting to receive some data back from

Persistent idle server connections - connections to servers that are waiting
for a client

Half-closed connections

It would seem that squid spends possibly a lot of time rechecking for activity
on sockets that may not need it. For example, if we've just sent a request
to a server, we probably won't expect a reply back immediately so that server
socket should be exempted from a poll check until say 3 times around the
poll loop.

Idle connections (while not polled explicity) still have to scanned each
time through the select() loop to see if they have a handler attached. This
seems like a waste. We should only be putting sockets onto the select list
if they are on a list of possible sockets, not scanning each time through to
find which ones.

I predict that with an efficient select() loop mechanism about 10% CPU could
be saved.

*) Capping number of sockets handled per select() loop.

With a large select loop, it may be possible that it takes a long time to
get to te end and call the next eventRun(). This can hinder squid's cleanup
and maintenance mechanisms. Perhaps breaking up LARGE select chunks into a
few smaller ones would be good.

*) Moving ICP query responder/receiver to a sub-thread.

This will be a BIG win by removing the ICP poll out of the main thread and
the associated processing that goes with it. This function has two operations.

1) Sending ICP queries and receiving replies

2) Responding to ICP queries

By breaking this out the parent thread won't need to worry about the ICP
socket and can just poll (similar to the way it currently does), but it
only needs to do a pointer lookup instead of an actual poll().

This could gain another 10%+ CPU based on our current ICP handling loads.
This load would also translate well to another CPU.

*) Inlining DNS lookups.

        I have suitable code for building/sending/receiving/decoding of
packets sent to a DNS server. It would just need to have a DNS socket
open full-time to send DNS requests out/receive DNS requests and do socket
waits on that. Alternately this operation could be pushed into a single
DNS thhread that handles the multi-plexing operation of multiple DNS
requests.

This way proper DNS timeouts could be introduced into squid.

*) Squid FS.

There's the CNFS filesystem but that has problems because objects will get
tossed even though they may still be needed.

I've done some research on this. Squid would work well with a 4K frag/ 8K
chunk
filesystem. Basically we want to write a stripped down version of UFS that
allows indexing by inode alone. I have a design here at Connect that works
out to an average of 2.5 disk accesses per new object pulled in, and 1.7
disk accesses per cache hit, based on a sample taken from our live caches.

Compare this to an average of approx 7 disk accesses per second with UFS on
a new object write, and an average of 3.5 disk accesses per cache hit.

This means about a 250% gain can be had from a customised UFS filesystem.

CNFS would give about a 300% gain (haven't checked - just guessing this one)
based on random disk accesses required.

*) Threading squid completely (!)

        I'll leave this open.

        Comments.....

        Stew.

-- 
Stewart Forster (Snr. Development Engineer)
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