Search squid archive

Re: cache_peer configuration is not being reliably hit in Squid 3.2.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux