On 20/09/2012 6:44 p.m., Nathan Hoad wrote:
On Thu, Sep 20, 2012 at 2:30 PM, Amos Jeffries wrote:
From your use of client_dst_passthru I assume you have this Squid configured
as a transparent interception proxy?
Yes, but it is also configured as a direct proxy.
This is apache format for web end-servers. Do you have anything in Squid
format which has better logging information for proxy details?
Which log format would be the most useful?
The squid one for this, it shows details about the source server. Which
will clarify whether Squid is using your peer linkage, DNS lookups, or
the client original TCP connection details.
Any cache.log traces of LIVE/DEAD status on the peer and indication of how
that interacts with the access.log timing? It could simply be the peer going
unavailable for a while.
I've made a change to the logformat here to give some more
information, and set the cache log to ALL,9.
1348118652.804 83 10.3.100.40 TCP_MISS_ABORTED/000 0 GET
http://appldnld.apple.com/iOS6/Restore/041-7181.20120919.lEuOK/iPhone4,1_6.0_10A403_Restore.ipsw
- HIER_DIRECT/150.101.195.90 - - 150.101.195.90 appldnld.apple.com 80
0.0.0.0 0
The suspicious thing about this is that client aborts after only 83
milliseconds. Barely enough time to get DNS data and start the TCP
handshake to upstream on a MISS. You can expect RTT to be between 50 and
150 milliseconds to most sites, depending on how far away they are. It
looks like the outcome of happy-eyeballs algorithm being applied over
your proxy and some alternative connection succeeded faster at 83ms.
Amos
