[squid-users] Fw: Squid 32-bit (2.7.2) much faster than 64-bit (3.5.11)

Patrick Flaherty vze2k3sa at verizon.net
Sun Dec 13 14:37:01 UTC 2015

Without 'dns_v4_first', what is sitting on top of the IPv6 connection
timeout? Is it a DNS lookup? Regardless of it being IPv6 timing out or IPv6
timing out falling back on IPv4 and having success of a long process to
maybe should be logged as a warning?

Second question, without 'dns_v4_first', was I experiencing a IPv6 timeout
and it falling back on IPv4? Because it does ultimately work... just slow.

Third question if the answer to question 2 is yes, should the DNS IPv4
lookup (successful) be cached so that next time it is fast?

Thanks Amos,

Message: 3
Date: Sun, 13 Dec 2015 19:20:35 +1300
From: Amos Jeffries <squid3 at treenet.co.nz>
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Fw: Squid 32-bit (2.7.2) much faster than
	64-bit (3.5.11)
Message-ID: <566D0E33.2060002 at treenet.co.nz>
Content-Type: text/plain; charset=utf-8

On 13/12/2015 11:44 a.m., Patrick Flaherty wrote:
> I agree, though it would be nice if there were some *warning* in the
CACHE.LOG about slow DNS transactions.

It's not the DNS itslf. That appears to be working fine.

dns_v4_first having a good effect means that the DNS for A and AAAA are both
happening fast. The TCP connection opening to IPv6 servers is timing out
(dns_v4_first sorts the A to be tried first at the TCP stage). That kind of
thing happens a lot.

If you have your timeouts set to be short Squid will log transactions as
TIMEOUT. Otherwise they are just like any other broken server IP address.
Retried, but slow in getting around to the IPv4 which works.



Subject: Digest Footer

squid-users mailing list
squid-users at lists.squid-cache.org


End of squid-users Digest, Vol 16, Issue 50

More information about the squid-users mailing list