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.16Received on Sat Feb 06 2010 - 11:42:58 MST
This archive was generated by hypermail 2.2.0 : Fri Feb 19 2010 - 12:00:06 MST