Re: [squid-users] Object Hit/Byte Hit accounting with Multiple Instances

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 16 Dec 2010 15:14:26 +1300

On 15/12/10 14:38, Michael Hendrie wrote:
> Hello List,
>
> I have server running 3 instances of squid-3.0.STABLE19 using a
> configuration similar to that documented at
> http://wiki.squid-cache.org/MultipleInstances. Each instance has all
> other instance configured as siblings using the "proxy-only" directive
> to allow sharing of cache without duplicating objects. This setup is
> working very well and has increased server performance by over 50%.
>
> I'm now trying to get an accurate indication of byte savings I'm
> achieving with this configuration however I'm not sure that the
> calculations I'm using are giving the correct results. Because each
> instance maintains a separate cache_dir this seems to be a little
> difficult to calculate. When instance 1 records a request as a MISS it
> may in fact be a HIT (from an entire system point of view) if the object
> is retrieved from the cache of instance 2 or 3.
>
> Using a combination of "squidclient mgr:counters" and SNMP, I grab
> counter values from each instance, tally and use the following formula
> to calculate the byte hit ratio:
>
> (mgr:counters:client_http.hit_kbytes_out +
> snmp:cacheClientHTTPHitKb.sibling_addresses) /
> (mgr:counters:client_http.kbytes_out -
> snmp:cacheClientHTTPHitKb.sibling_addresses) * 100 = % cache byte hit ratio
>
> Using this formula, I always seem to get inconsistencies between what
> squid reports and what my benchmarking tool reports (web-polygraph). In
> the few cases I've checked so far, squid is always reporting a 4-5% less
> byte hit than what web-polygraph reports.

That sounds about the size of header overheads to me.
Give 3.2 workers a try out now and see if that is usable. The stats
calculations are fixed there for multiple workers.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.9
   Beta testers wanted for 3.2.0.3
Received on Thu Dec 16 2010 - 02:14:31 MST

This archive was generated by hypermail 2.2.0 : Thu Dec 16 2010 - 12:00:03 MST