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? Let's say we split the parameter into an high and a low watermark (min-idle and max-idle). 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? After all, it's just the way Apache handles the idle workers pool, so it's also pretty well understood by system administrators. Kinkie
