Re: Squid-1.1.20

On Wed, 8 Apr 1998, Evaghelos Tsiotsios wrote:

> We have recently upgraded the Squid installation in our site (80 hosts)
> to 1.1.20. (Linux kernel 2.0.33).
> There are a couple of things I' d like to ask, though.

Welcome to Squid! :-)

> I am noticing myself - and getting some complaints from colleagues also-
> that often enough we get read error messages and the connection is
> aborted. If the user insists (reload twice or three times) then he/she
> gets the page he wants. Also, at times, not the whole page is downloaded
> leaving some elements 'blank'.

This is the exact problem that led me to write the connection-retry patch,
available at <ftp://ftp.comshare.com/pub/squid/>.

What's probably happening when the users are reloading two or three times
is that they are in effect "redialing" a busy server. According to the
RFC, a server does not have to actually tell the client that it is busy
with a 5xx HTTP response, it can simply refuse connections. The effect of
this is that it is hard to tell from connection to connection whether a
server has crashed or is just very busy.

And since some hosts have multiple IP addresses, if one server isn't
responding, one or more of the others usually are, but Squid and browsers
don't know this and so give up on the first refused connection.

The retry patch will try single-address hosts up to three times
(configurable), and will try every address of a multiple-address host
before returning an error to the Squid user. And unless the server is
*extremely* busy or *really* crashed, it will almost eliminate any
appearance of problems at the end user's browser. A side benefit is that
it routinely allows a 99+% ipcache hit rate, because it keeps track of the
state of addresses in the cache rather than just dumping the bad ones.

Now, if a server actually does return a 5xx error stating explicitly that
the server is too busy (which in my own experience is a fairly rare
event), the user will recieve that "too busy" message without any retry
attempts. This case is more difficult to retry since it involves parsing
the text returning from the server and recreating a filehandle much later
in the connection process. However, in this case the user is explicitly
told that the problem is at the remote server's end of the connection, so
they won't call *you* and whine about it.

Let me know if you have any questions about the patch.

        -Mike Pelletier.

--
Support the Astronaut Dollar Coin Initiative:
                           <http://home.rmi.net/~dcarr/dollar.htm>