This post has NOT been accepted by the mailing list yet.
Dear squid users,
we have some performance issues with squid. A necessary information is: we have one big central proxy (parent) and each department has its own proxy (child).
If you watch the waterfall charts (i.e. from Firefox) you can see, that some (random) requests take exactly 30 seconds. If we use Wireshark we can see, that the client send the request normal to the child proxy. After 30 seconds we can identify the request from the child proxy to the parent proxy. The response from the parent proxy comes instantly. We guess, that this should be caused by a timeout.
We have set dns_timeout to 9 secs and peer_connect_timeout to 13 secs. Since then, the long running requests were reduced to 13 secs, therefore it should be the peer_connect_timeout. We may lower this parameter to 3 seconds to remove the symtoms, but we want to find the root cause.
The offical explanation is: "This parameter specifies how long to wait for a pending TCP connection to a peer cache. The default is 30 seconds." The question is: what means "pending" in this context? Is the TCP session already established or is it a creation timeout (3 way handshakes). There are no TCP retransmissions in this time frame (between request sent and late response).
Affected child proxys run squid (Version 3.1.10 or Version 3.4.14) on RedHat 6: Linux 2.6.32-573.7.1.el6.x86_64 x86_64