SUMMARY: Slowness of Squid without any apparent reason

From: Stephane Bortzmeyer <[email protected]>
Date: Thu, 21 Nov 96 11:31:13 +0100

On Friday 18 October 96, at 15 h 55, the keyboard of Stephane Bortzmeyer
<bortzmeyer@pasteur.fr> wrote:

> Our largest cache in France is an AlphaServer 1000 (Digital Unix 4.0)
> running Squid 1.0.18. It is incredibly slow, taking several seconds to
> deliver a very short HTML page (already in the cache) and sometimes
> dozens of seconds. The variation of response times is important. (A

The machine works much better now. The only remaining problem is that we
don't know why :-}

Unfortunately, because of the lack of time, because we need this cache
and we need it now, we didn't have time to perform a lot of scientific
measures. The following changes were made to the machine, but I cannot
say which are really significant :

- cache_mem severely decreased (Squid eats a lot of memory for other
purposes, watch the swapping),

- netconfig "hiperf" (we are sure it wasn't a network problem, since
retrieving from the cache machine itself was as slow),

- system config file changed. maxusers increased to 256. TCP tuning
according to <http://www.digital.com/info/internet/document/ias/tuning.htm
l>. Note that, in the worst moment, the machine was still very fast to
make things like gcc compilation. So, the problem was probably inside
Squid.

- switch to Squid 1.1, with its two-level directory structure (our
directories were huge, with a long time to do a simple 'ls'). We have
near a million of files in the cache.

- gcc 2.7.2.1 (before that, we used Digital's cc),

- GNU malloc (several Digital Unix users reported a noticeable
improvment).

Now, the machine has a normal behaviour. Even now, fully loaded (14
gigabytes in the cache, five TCP connections per second - and more UDP -
during the working hours), we have almost always less than 0.3 second to
retrieve a small page (already in the cache) from a remote client.

This is too early to be *sure* the problem is solved (we have to add all
the new clients which were "backloged") but I think we're on the right
track.

Many thanks for the help and support from Daniel Azuelos <dan@pasteur.fr>
, Christophe Wolfhugel <wolf@pasteur.fr>, Claude Scarpelli
<claude@infobiogen.fr>, Ong Beng Hui <ongbh@staff.singnet.com.sg>, Brian
Denehy <B-Denehy@adfa.oz.au>, Redfern Ian <RedfernI@logica.com>, James R
Grinter <jrg@demon.net> and of course Duane Wessels who do not only write
Squid, he debugs it as well :-) The intergalactic network of cache
managers work well.

Of course, we're ready to exchange experiences with Squid managers on
such machines.
Received on Thu Nov 21 1996 - 02:31:32 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:33:35 MST