Re: comm_*_incoming changes

Stewart Forster <slf@connect.com.au> writes:
>
> Actually, thinking further (sorry about the multiple posts), if we
> just start up with a sensible value (say 16, and let 16 (32?) be the maximum
> number of I/O requests between polls) and let it float about slowly, then
> it's going to tune itself quite happily and there becomes no need to confuse
> the user/operator with extra config variables since squid will just adjust
> to the load it sees. Just set a hard minimum of 1 and a hard maximum of 16
> (32?) and it should be fine. The only gotcha I can think of is responding
> too slowly to load spikes if the value moves too slowly, but load spikes of
> that large of a change over a few seconds are rare.
>
> What do y'all think (who actually care about this)?

This sounds pretty good. Except that I'd put the maximum two or four
times the starting value (i.e. start at 16, and max out at 64?) What
it means is that busy caches with no neighbours are going to 'tune
out' the ICP checking. Which sounds just about right.

Actually I guess see an argument for putting the maximum up into the
4000 odd. (i.e. file descriptors * 2 or 3).

Becuase it'll get called at least once per main loop, it'll clear all
the packets every time it's called, the main loop should be being run
about 100 times/sec anyway, let it drift REALLY high for large caches
with quiet neighbours sounds like just the trick.

Michael.
Received on Tue Jul 29 2003 - 13:15:50 MDT