Re: Observation about icp_query_timeout in Squid 2

Chris Teakle writes:

>There seems to be something wrong with the way Squid 2 calculates the
>"optimal ICP query timeout value", when icp_query_timeout is not set.
>
>We run two busy University caches (platform is Alpha, Digital Unix
>4.0D). Previously they were running version 1.NOVM.22, with
>neighbor_timeout defaulting to 2s. At the time, direct fetches
>consituted around 30% of all external fetches, as reported by
>Calamaris. The remainder are fetched from each other as siblings, or
>from parent RNO caches. All of these peers are in the same machine
>room and responses have fast round-trip-times.
>
>When they were upgraded to 2.0.RELEASE (later 2.0.PATCH2), I opted not
>to set icp_query_timeout and to let Squid set the timeouts
>automatically. But the proportion of direct fetches jumped to nearly
>60%. A large proportion of misses were being logged as TIMEOUT_DIRECT
>fetches.
>
>Putting squid into debug mode revealed that ICP queries were being
>given very low timeouts, often well under 100ms. Thus squid was all too
>often giving up on its peers and going direct. This of course resulted
>in missing out on alot of potential peer hits.
>
>When I set icp_query_timeout to 1000 (ms), the TIMEOUT_DIRECT fetches
>virtually disappeared and the direct fetches dropped back to around 30%
>(In fact a value of 250ms gave much the same result.)
>
>It seems to me that something must be wrong with the automatic timeout
>calculation for it to consistently underestimate so badly.

The algorithm is to double the average of your peers ICP RTT values.
What does

        client mgr:server_list | grep RTT

look like?

Duane W.
Received on Tue Dec 01 1998 - 10:34:29 MST