Re: [squid-users] Managing timeouts

On Sun, 25 Oct 2009 22:43:53 -0500, Matthew Young <myoung24866_at_gmail.com>
wrote:
> Hello all
>
> I have a group of proxy users who are not technical at all, and it is
> very common for them to complain that the "network is slow" because
> there job consists of browsing sites all day and sometimes they are
> just lucky that they hit remote servers which are non response, or
> initiate the connection but never feed data thus they see their
> firefox as loading and loading and they next thing we know they also
> think there "computer is slow". They cannot tell the difference
> between a local network issue and a remote server issue.
>
> Id like to drop down the possibilities of this and set a timeout of 30
> seconds, my goal is if the remote site is non responsive (waiting for
> data) id like to timeout the connection in 30 seconds tops, if
> possible display the timeout message.
>
> My question is, what are they related time outs within the config that
> are safe to modify? I modified the read_timeout (default 15min, yes
> some users actually stare 15 min on the screen) to 1 minute but for
> some reason it didnt take place.
>
> Also, does the cache manager offfer a way to list the slowest queries
> for inspection?
>
> Thank you.
>
> -- Matt

When they are finished the native squid format lists the duration of a
request in milliseconds (column 2).

I'm not aware of any way to find the longest existing current connections.

May not be relevant here but SqStat is a cool little utility very good at
displaying the current ones in realtime on demand.

The timeouts I can think of being relevant to overall transaction delay on
failures are request_timeout, read_timeout, connect_timeout,
forward_timeout and dns_timeout.

Of those request_timeout is the most critical since it limits the total
time the sending and receiving of the request may take (read_timeout
default allows 15 min for each byte to come in, but request_timeout will
still terminate the request at ~4minutes if its not finished by then).
It's a bit loose on GET requests (should be very short. 10 seconds etc) but
very long for POST (minutes or hours for huge file POSTS). It starts
_after_ the connection is successfully opened.

Second most critical is a mixture of the other three. AFAICT:
 read_timeout should be larger than: dns_timeout + forward_timeout
 forward_timeout should be larger than connect_timeout times the number of
IPs each website has.

This is based on my observations of a few bugs I suspect of existing
because read_timeout or forward-timeout was shorter than the other two
settings.

Amos
Received on Tue Oct 27 2009 - 00:58:59 MDT