On 27/03/2013 5:49 p.m., Mark Davies wrote:
On Wed, 27 Mar 2013, Amos Jeffries wrote:
Squid has a partial implementation of happy eyeballs added to 3.2+
which performs the parallel DNS lookup portion of the algorithm
but does not perform the parallel v6+v4 SYN portion which halves
the server TCP capacity for only rare gains (like karen).
OK makes sense.
Also, be aware the timeout settings in Squid-3.3 connection setup
have undergone a major redesign.
[...]
So what you should be seeing in 3.3.1 is that connection to
karen.net/nz takes no more than: connect_timeout multiplied by
the number of IPv6 karen presents to you, plus the amount of time
the IPv4 takes to respond with data.
In terms of actual page viewing its worse than that. It's as you say
to get the base page but then you have to repeat the wait for any
elements the page references (css, images etc) before the browser
renders the page (depending on how much parallelism the browser
implements in grabbing the elements).
That should not be an issue unless the site has really gone out of its
way to be unfriendly. Squid maintains an internal DNS cache and
remembers which IPs are failing so it can try the working ones faster on
future requests. It should also be using persistent TCP connections to
fetch all the objects within the page (unless you disabled those
performance features).
NP: connect_timeout default is still the old 60 seconds, you can
safely drop it to a few seconds if you need to in 3.3.
I've dropped it to 10 seconds as that shouldn't interfere with any
real site and lets sites like karen eventually render. I might reduce
it even more once I decide what a legitimate max connect time is in
todays internet.
Rule-of-thumb is to use twice the ping time from somewhere on the far
side of the world or something like that.
Amos
