Re: [squid-users] cache_peer configuration is not being reliably hit in Squid 3.2.1

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
Received on Thu Sep 20 2012 - 11:19:33 MDT