Adrian Buciuman wrote:
Hi, Running squid 2.6 STABLE 21 from Centos 5. I've seen a issue with a site. The problem is that the browser locks for some time, and only afterwards the user is able to interact with the site. (The site has Flash based content or something similar). My feeling is that this annoying delay is bigger when using squid than when using direct connection to Internet. I believe the browser is waiting for some tracking/adware gifs to load, and the webserver is down. If using direct connection, the connection to the ads-server will timeout in 20-30 seconds, the browser will display a gif-placeholder, and the user can happily use the site (or they can reload the page to see all the ads :-) ). If using squid, the timeout will occur after a longer time. I've used tcpdump to find how is squid managing timeouts and retries. Is looks squid is retrying a TCP connection to the origin webserver for 3 times.This retry happens even if the webserver has only one IP. Each of the three connection attempts consists of multiple SYN sent. In the default config, Squid will return a failure to the browser after 3 minutes (connect_timeout is set to 1 minute)
Lucky you. Squid-2.6 tries 10 times. But something is timing it out before all 10 are completed.
I've made no tests in case of connection actively refused by the webserver (tcp reset). I don't know if they are (and should be) treated or not like a tcp timeout for the purpose of retrying. Since TCP has its own built-in retry mechanism in case of failure to respond to the initial SYN, the tcp stack would retry even if squid made a single connection attempt per IP (in this case squid should limit the number the IPs tried). Workaround 1: lower the connect_timeout. For instance, to get a total timeout of 30 seconds, set the connect_timeout to 10 seconds. The problem with this is that if a web/ftp server is slow to respond to SYN, the connection may fail. Workaround 2: set both forward_timeout and connect_timeout to 30 seconds. The problem is that you miss the chance to try a second/third IP.
So set connect_timeout less than forward_timeout.
The new option forward_max_tries set to 1 may solve this (haven't tried) , but it has broader consequences and is not yet in stable releases.
That will prevent failover between multiple sources. Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE23 Current Beta Squid 3.1.0.16
