RE: [squid-users] Delay Pools

> Correct. Pools might temporarily be slightly overdrained by a small
> amount.

At most, by one less than the number of simultaneous streams
in the pool in question (sometimes 4 - 10 per web client going
through the proxy, if they're using a web browser that does a
lot of simultaneous streams).

> This to prevent complete stalls of connections when there is
> competition over the available bucket space IIRC.

The most important thing when there's competition over bucket
space is commGetSlowFd() - delayed file descriptors are always
processed in a random order rather than in any sequential order
(arguably it would be nice to do this always to all file
descriptors).

The reason behind the negative numbers is that we always
try to read at least one byte if a file descriptor is chosen to
be read from. It helps in weeding out dead file descriptors
for one thing, and it keeps the code much simpler than adding
more special cases all over the case for "if we chose the
file descriptor for reading, then changed our mind when we
got around to reading from it".

Basically if there are any bytes in the pool, then we will
choose all streams which go through the pool as "potential for
reading" when asking the kernel (via poll()/select()) which
file descriptors are available for reading. Then when it
comes to time to do the actual reads, the first stream (chosen
at random -- every second a new randomly chosen file descriptor
gets first go at the newly allocated bytes in the pool) may
actually exhaust the pool and the subsequent streams which
were ready to be read from would in that case only have one
byte read from them.

David.

> Yuriy Kuznetsov wrote:
> >
> > 10x Henrik
> > After rearranging all is OK... But who may answer what
> negative numbers
> > mean into
> > delay statistic... Big negative number big overload (%) or...?
> >
> > Pool: 1
> > Class: 1
> > Aggregate:
> > Max: 12000
> > Restore: 12000
> > Current: -40
Received on Sat Jan 05 2002 - 05:48:56 MST