RE: [squid-users] Squid usage

> Intuitively it seems that you could make use of a
> multiprocessor box by creative use of a cache hierarchy ? I'm
> thinking maybe 3 copies of Squid; one running on the standard
> port to dispatch requests, designating the other 2 as
> proxy-only parents in a round-robin scheme. Unless there was
> some nasty software bottleneck in the "dispatcher" squid,
> this should be able to balance load across two CPUs.

Yes. This is wildly inefficient though, both CPU and memory-wise.
A better approach would be to have a LVS splitting the load
to two cache-digest-coordinated squids.

> This assumes of course that the CPU load of a proxy-only
> squid is significantly lower than one that manages a large cache.

It is, however HTTP parsing and IO management _has_ an impact.

> Also, I would expect that you could improve overall response
> times on a loaded system like this by _decreasing_ the size
> of the cache_dirs. I'm assuming that cache management

Correct.

> overhead increases (logarithmically ?) with the size of the
> cache. Given usage patterns that I've seen at a few sites,

AFAIK it's exponentially (yuck). There are a few efforts underway
to change this, but don't hold your breath.

> the hit rate between a 10GB cache and a 20GB cache is not
> really significant - not compared with the 0.6 second cache
> hit time - I generally see times in the 0.05-0.1s range (and
> not even on a real CPU).

Yes.

> Disclaimer: all this is theory - I haven't got enough traffic
> here to consider trying this kind of tuning.

I do (yesterday I went very close to 1 million hits/hour).
My comments are inline.

Just a side-note, Linux-2.4 and its deserialized TCP/IP stack could
lend you a hand. My system spends 40% CPU in kernel-mode, most likely
managing TCP/IP. IF the OS can offload that to the second CPU,
it means that the squid _will_ get more CPU to do its stuff. In an ideal
world, given these numbers, it might even get to load 80% of the second
CPU.

-- 
	/kinkie