On 09/22/2013 12:51 AM, Kinkie wrote: > On Sun, Sep 22, 2013 at 1:14 AM, Alex Rousskov > <rouss...@measurement-factory.com> wrote: >> On 09/21/2013 04:38 AM, Kinkie wrote: >>> Amos already answered very fully. >>> To me, this just seems a worthwile optimization. >>> Background neighbor probe with dummy request and cache_peer idle=num >>> seems reasonable in terms of effectiveness and implementation effort; >> >> Unless we bombard a peer with new connections every few hundred >> milliseconds, the effectiveness of the above combination (for the >> problem at hand) would be close to zero. To solve the problem, the >> criteria for opening a new connection should be "not enough opened >> connections" rather than "we have not probed that peer for a while". >> While you can emulate the former by using small timeouts, the overheads >> make such emulation prohibitively expensive.
> Why do you say that? I am not sure which part of my response you are referring to, but I hope you agree that probing a peer proxy every few hundred milliseconds is prohibitively expensive. > Let's say we split the parameter into an high and > a low watermark (min-idle and max-idle). This goes beyond frequent probe + idle=N solution that you proposed and I was commenting on. > In the pconn cleanup, if > we're above max-idle, we start closing some pconns, if we're below we > start more aggressively "probing" forcibly using new conns (see point > 1), and adding these to the pconns pool. Sure, it won't _fix_ the > problem but at least it'll make it a bit better, won't it? Perhaps, but I would like to arrive at a solution that will fix the problem. Based on the discussion with Amos, it looks like a "proper" idle=N port to Squid3 might be it. Thank you, Alex.
