On 20/12/2011 9:56 p.m., Sekar Duraisamy wrote:
> Hi ,
>
> Iam getting more read timeout while iam using Squid proxy with
> persistent connection off state.
A strong sign that there is something broken at the TCP level of the
networks your traffic travels over (yours, your suppliers or peers).
Usually due to ICMP blocking preventing TCP control messages moving
around the network. Possibly also ECN or window-scaling issues if you
have old hardware/software sitting around the network.
>
> What is the maximum values for read_timeout and connect_timeout.
Just over 136 years. Operating system limits on TCP packets and
connection state timeouts will occur much sooner.
Read timeouts are not solved by extending the read wait, but by
decreasing it causing squid to identtify the problem faster and perform
whatever recovery it can. The default is 15 minutes. Way more than long
enough for most of the Internet (only the spacecraft control connections
need longer timeouts).
It depends on your squid version, but connect_timeout may be for one TCP
connection (Squid-3.2.0.9 and later), or for a whole set of IP addresses
including the DNS lookup time (for Squid-3.2.0.8 and older). That
difference affects how to tune for best results; 3.2.0.9+ you should
tune connect_timeout *down* to make Squid failover quickly and avoid
long TCP waits getting to a working IP faster, older Squid you tune it
_up_ to allow more time for the TCP wait to happen (maybe several times)
and a good IP to be found somewhere in the set.
NP: I recommend enabling persistent connections since it has some effect
reducing the amount of problems you face. If you need constant turnover
of ports (ie for a reverse-proxy or thousands of clients) you can set
the persistence timeout low to cause that and still gain most of the
benefits of HTTP persistence.
Amos
Received on Tue Dec 20 2011 - 10:20:39 MST
This archive was generated by hypermail 2.2.0 : Tue Dec 20 2011 - 12:00:03 MST