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
