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
