Re: comm_*_incoming changes

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

> How about incoming_idle_poll, and incoming_active_poll?
>
> Further, how about a floating value that moves between these two
> values. Say move it up by .01 for every no-active timeout, and down by .01
> for every time there's some action. (Of course then take the integer
> component of that when working out when to next poll). That way if it's'
> sitting busy at 2 (the default min) and we don't have activity for a brief
> bit, then it slowly moves to the slower poll rate. That way the current
> value could be printed out on some stats page to help users tune it
> accordingly by watching where the value sits at. It's it's constantly
> maxed or minned out, they then know what to adjust.

        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)?

                Stew.

-- 
Stewart Forster (Snr. Development Engineer)
connect.com.au pty ltd, Level 9, 114 Albert Rd, Sth Melbourne, VIC 3205, Aust.
Email: slf@connect.com.au   Phone: +61 3 9251-3684   Fax: +61 3 9251-3666
--MimeMultipartBoundary--