Re: [squid-users] Squid usage

robin.garner@iname.com wrote:

> 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.

Unfortunately there /are/ some nasty software bottlenecks in Squid.
But, there are folks who are running multiple Squid processes on the
same machine, using policy routing to distribute the requests to the two
processes.

It will work...to some extent.

> 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, but probably not significant enough.

> 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).

You must have missed my first post on this issue, where I suggested
increasing the size, and /why/ I suggest it. (Normally, I'm yelling at
people to shrink their bloody object stores, because they are trying to
run 40GB of cache from 128MB of RAM and then complaining about 'memory
leaks'!)

This is a special case...He is supporting 3000 simultaneous users and
6000reqs/minute. That's a heavy load...but he's only allocated 7GB of
cache storage. In this case, I kind of suspect that replacement is
actually a pretty big load for his disks...Deletes are a slow process on
some file systems, and they are never 'free'. Deletion in Squid is
particularly damaging to performance (when a cache is empty, you can run
at about a 20-50% higher request rate, but as soon as deletion starts,
things start to slow down and CPU usage climbs).

I don't encourage him to increase his object store in order to raise his
hit ratio. I've been preaching 'smaller is faster, and will not
adversely effect hit ratio' forever. But if it is too small (not a
problem I've seen mentioned here very often) you can actually hurt
performance. So, it won't make a huge hit ratio difference...the
problem I'm trying to address is performance.

Besides, he has 2GB of RAM. He can certainly handle more than 7GB of
cache object storage. 24GB is probably about right for his loads and
his system.

> 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.

Yep. And that's all I've been trying to address. I think if you
re-read my posts you'll see quite clearly that I don't care one bit
about his hit ratio (I only mention it in passing at the end of the
second post).

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

It's not theory for me at all. I have several caches running at this
load and quite a bit more.

> 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.
                                   --
                      Joe Cooper <joe@swelltech.com>
                  Affordable Web Caching Proxy Appliances
                         http://www.swelltech.com
Received on Tue May 15 2001 - 04:31:02 MDT