Re: fine tuning squid.conf in 1.2.beta22

>Duane, I think based on what we're seeing down a reasonably lightly loaded
>ethernet to two parent caches (somewhat heavily loaded) that the two variables
>neighbour_timeout and dead_peer_timeout should be at least doubled, to remove
>the 'Detected DEAD / Detected ALIVE' sequence in the cache.log.

The dead_peer_timeout can affect the alive/dead reporting, but I think
the neighbor_timeout can not. ICP replies arriving after the timeout
are still used to mark the neighbor as alive.

Also, now in 1.2 the neighbor_timeout is calculated dynamically (unless
you override it with a fixed value). In the new scheme the (dynamic)
timeout is twice the average of the average RTTs for all (alive)
neighbors who you sent a query to. This doesn't work so well when one
neighbor has a very high RTT compared to others. Arguably, we should
use the max of the average RTTs instead.

>You may want to add some comment to the .conf about what the hold-dead time is
>so its clear what the shape of the sawtooth will be. Is there an explicit
>variable for the dead-time I've missed?

The dead_peer_timeout is probably overloaded and the algorithm is
kind of complicated. If we haven't sent any queries in the last
'dead_peer_timeout' seconds, then we assume the neighbor is alive
(but we don't log it as ALIVE). Otherwise, if we have recently
sent queries but have no replies after 'dead_peer_timeout' seconds,
then we log it DEAD.

Also, I recendly committed a change to the beta code which
requires 10 failed TCP connections (instead of 1) to call a
neighbor DEAD. 1.1.X already does this.

>Could the -DNO_CACHE_ACL be elevated to configure --enable/disable status?
>Jointly with this, I think the no_cache options should be enabled by default,
>and the two associated

The no_cache feature is already in 1.2.X. You don't have to define or
--enable anything. Its optional in 1.1.X because I told myself
"no new features will be added to 1.1"

>#acl QUERY urlpath_regex cgi-bin \?
>#no_cache deny QUERY

ok, I'm game.

Duane W.
Received on Wed Jul 01 1998 - 23:42:14 MDT