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.

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

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 overhead increases (logarithmically ?) with the size of the cache. Given usage patterns that I've seen at a few sites, 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).

In general, I think the key statistic we should look at is the speedup, ie (all_request_time -cache_miss_time) /all_request_time. In this context, attacking the time per cache hit is going to bring better results than a few extra 0.1% on the cache hit ratio.

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

Robin

BLATS@fr.ibm.com wrote:

>
> I have several questions
>
> 1) could I add another CPU (bi processor)

Yeah, but it won't do much good. Squid is single process, and doesn't
scale to multiple processes very well. It can help a little bit though
since you have diskd processes... (But you'll find CPU usage of the
other processor will only reach about 10-20%.)

> 2) what are the interresting item in the stats

Cache Hits: 0.61549 0.55240 -- This is quite slow for hits.
It means your box is probably being overloaded quite a bit.

---------------------------------------------------
Get free personalized email at http://www.iname.com
Received on Tue May 15 2001 - 03:10:59 MDT