Re: Squid 2.2.STABLE2 & choice of parent

John Line (as web server manager) wrote:

> (1) Why is it logged as TIMEOUT_FIRST_UP_PARENT? That's misleading, since
> it wasn't chosen due to ICP timeout... (I'm not sure what it should be
> logged as instead, though; FIRST_UP_PARENT would tend to imply it was the
> first-choice route, when it wasn't; perhaps TIMEOUT_ is has the most
> appropriate meaning. The more general question, I suppose, with Squid
> retrying failed retrievals automatically, is whether there is intended to be
> a distinction between the description in the log of requests that are routed
> in a particular way as a result of failure by a preferred retrieval option,
> of if they're intended to be logged as if the routing that was actually used
> had been the first choice.

The ICP timeout logging is very primitive. If there was a ICP timeout
then the log code is prefixed with TIMEOUT_ regardless what the final
selected path is.

I agree that there could be improvements with respect to the logging
when a selected path fails.

> (2) Is there a check somewhere to avoid the same parent being chosen as
> FIRST_PARENT_MISS peer and also as the fallback FIRST_UP_PARENT peer? Not a
> major problem, I suppose, unless a *lot* of requests were routed in that way
> and the peer was unresponsive, so that the requests would take twice as long
> to fail (assuming the problem affected all requests; it's possible the first
> would fail and the second succeed, if the peer status was fluctuating
> rapidly e.g. close to running out of filedescriptors for peer sockets).

Nope. I have thought of adding something like this, but I have not got
to it yet (very low priority).

I would say this specific example is mostly a matter of proper dead peer
detection. A peer which is flaky should get a lower priority even if it
has a good RTT. However, it is not obvious how to do such a thing.

/Henrik
Received on Tue Jul 29 2003 - 13:15:58 MDT