The use of cache digests is selected per peer relation. There is no need
to reconfigure siblings unless you want these to be using your cache
digests rather than or in addition to ICP.
Both peers in the digest relation obviously needs to have support for
cache digests enabled.
If you want to maximise the benefit of cache digests in peering response
time then also use the no-query option. If you don't then cache digests
will only be used if there is a cache hit in a digest, and ICP will still
be used for all other misses.
Regards
Henrik Nordström
Squid Developer
On Tuesday 08 January 2002 14.49, Van Bossche Koen wrote:
> Hi,
>
> First of all happy New Year to you all!!
>
> Can someone explain to me if enabling my squid with cache digest in
> stead of ICP could make a big difference in performance.
> I have following stats :
> From cachemgr - Connection information for squid:
> Number of clients accessing cache: 645
> Number of HTTP requests received: 637636
> Number of ICP messages received: 455063
> Number of ICP messages sent: 455063
> Number of queued ICP replies: 0
> Request failure ratio: 0.00%
> HTTP requests per minute: 88.7
> ICP messages per minute: 126.6
> Select loop called: 30718479 times, 14.047 ms avg
>
> From squeezer :
> Performance:
> No of req Xfer(kB) Xfer speed
> (kB/s) Xfer % Times to direct
> Total traffic 335584 1899114 2.506 100.00 0.50
> Direct fetches 2725 72905 5.026 3.84 1.00
> This server 70459 87261 7.135 4.59
> 1.42
> Other servers 304575 1733066 2.425 91.26 0.48
> Cache hierarchy 375034 1820328 2.504 95.85 0.50
> Total traffic should at least be higher than 1 (right), this way direct
> goes faster and
> makes no sense to use a proxy.
>
>
> What impact would this have not only for my parents but also for the
> childs. Do I need to reconfigure them all then?
> What do you guys advise, I already did the tuning section.
>
> BR,
> ./koen
-- MARA Systems AB, Giving you basic free Squid support Customized solutions, packaged solutions and priority support available on requestReceived on Tue Jan 08 2002 - 11:12:44 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:05:41 MST