Re: steady peer connection pool

On 22/09/2013 11:14 a.m., Alex Rousskov 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.

I'm not proposing that as a full fix but as one soure of reducing the
total handshake load and delays. Even one probe per second re-used is
one user happier.

Also, is this peer actually having connections re-used? or closing them
constantly?
With a peer under relatively constant load the connection count should
accumulate to a steady state where existing connections are being
finished with fast enough to handle the new requests. Saving the probes
and maintaining idle= pool count are "just" to hide the churn from
closed connections and lower the ramp-up delays toward peaks.

> 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.
>
> The idle=N option is very similar to what we need, but has the wrong
> focus on keeping already opened connections, rather than making sure
> that N connections are ready for use at all times.

Huh? no. idle=N is focused on having N connections _open_ for immediate use.
The pool is a temporary queue of those open connections waiting to be
re-used.

> If we ignore the startup problem (no connections at all) and that pconns
> in the idle pool get closed (for various reasons), then the combination
> of probes and idle=N will be the right solution. Unfortunately, those
> things are at the core of the problem and cannot be ignored.
>
> BTW, I would not be surprised if some setups using idle=N would prefer
> to use hot=N instead (or whatever we end up calling the proposed feature).

If hot=N is set to a few hundred (or thousand) can you be sure the local
firewalls etc will not block the connections as the sudden SYN flood
appears?
And how long will the Squid startup/reconfigure processes be delayed by
perforing that many SSL handshakes in one burst?

I note that this problem is the one being resolved by HTTP/2 framing.
Getting that working would seem to be the best long term solution. Each
HTTP/2 peer TCP connection handles up to 2^31 simultaneous
request/response pairs.

Amos
Received on Sun Sep 22 2013 - 02:17:55 MDT