RE: [squid-users] Poor Squid performance problem (bis!)

From: GUIDOUX R InfoEdpEtcDep <Richard.Guidoux@dont-contact.us>
Date: Thu, 30 Aug 2001 11:39:46 +0200

Thanks to all for your return ...
About it, here is what I've done to increase my Squid load :

(/etc/system)

set rlim_fd_cur = 256
set rlim_fd_max = 8192

(/etc/rc2.d/S99tuning)
ndd -set /dev/Tcp tcp_conn_req_max_q 1024 (default = 256)
ndd -set /dev/Tcp tcp_conn_req_max_q0 2048 (default = 1024)

I've decreased my squid param. CACHE_MEM to 50M

Then, I have run reconfigure (it's OK, now Squid starts with 8192 FD)

My problem is that I still have the same number of simultaneous HIT ...
(about 1000)

The only thing left I see is that 'netstat -an | wc -l' always return me
about 4100, whether I've got 100, 200 or 1000 clients connecting at the same
time (asking each for several objects ...)

4100, it's almost 4096 ..., is there such a Squid limitation ?

Richard.

-----Message d'origine-----
De : Robert Collins [mailto:robert.collins@itdomain.com.au]
Envoyé : samedi 25 août 2001 04:12
À : GUIDOUX R InfoEdpEtcDep
Cc : 'squid-users@squid-cache.org'
Objet : Re: [squid-users] Poor Squid performance problem (bis!)

On 24 Aug 2001 18:15:48 +0200, GUIDOUX R InfoEdpEtcDep wrote:
> Hello,
>
> Does anyone have any idea about it ?
>
> sorry for this second mail, but I'm really blocked and I can't go on with
> using Squid if I can't get better performance !
> usually, when I perform these tests, caches are 100% CPU loaded. Here it
is
> not even the case. I'd like to identify the (hard or soft) limitation and
> get rid of it.
>
> Any help will really be appreciated ...

Squid will typically need 3 fd's per 'hit'. 1 for the upstream socket, 1
for the downstream socket, and 1 for the store file.

So to handle 2000 concurrent connections, you need ~ 6000 fd's.

When you run ./configure squid TESTS your system to see how many fd's it
can obtain. You need to set your limits _before_ running ./configure or
else it will get limited to your user setting.

Rob

> Bye,
>
> Richard
>
>
>
> > -----Message d'origine-----
> >
> > Hello,
> >
> > i've got a little problem with Squid configuration tuning :
> >
> > I've got Squid 2.3 STABLE 3 under Solaris 8
> >
> > My server is quite powerful : Sun Fire E-280 with 2 procs & 1 Go Ram
> >
> > I want to have my squid deal as most simultaneous connections as
possible
> > (for its tuning)
> >
> > To measure connections, I use little tool which send HTTP requests of 1k
> > cacheable pages to 'squid'
> > If it can help, here is my request : "GET
http://192.xxx.xxx.xxx/1k.html/
> > HTTP/1.1"
> >
> > My problem is that I can't deal with more than 1000 'simultaneous hits'
> > (whereas I get more than 2000 with other caches of little size)
> >
> > I have checked CPU & Memory, it's OK :
> > I've got 30% Free on 1 CPU, and 60% on the other (besides, how does
squid
> > deal with multi processors?)
> > Also, I've got more than enough RAM (or swap) free
> >
> > So, my question is : why not more than 1000 connections ?
> > Is it due to File Descriptors limitation ?
> > I have set Soft limit to 1024 and Hard Limit to 4096 (it seems that
Squid
> > can't manage more than 1024 FD).
> > I use poll() method for file access.
> >
> > I'm almost sure there is one parameter i need to change, but I can't
find
> > it (i've tried almost all Squid Tags)
> > here is my squid.conf file (it's really minimal ...)
> >
> > # NETWORK OPTIONS
> > http_port 3128
> > icp_port 0
> >
> > cache_effective_user squid
> > cache_effective_group squid
> >
> > cache_mem 500 MB
> >
> > maximum_object_size 4096 KB
> > minimum_object_size 0 KB
> >
> > # OPTIONS WHICH AFFECT THE LOGs
> >
> > pid_filename /usr/local/squid/logs/squid.pid
> >
> > cache_dir ufs /usr/local/squid/cache 2500 16 256
> > cache_log /usr/local/squid/logs/cache.log
> > cache_access_log /dev/null
> >
> > pid_filename /usr/local/squid/logs/squid.pid
> >
> > # OPTIONS FOR EXTERNAL SUPPORT PROGRAMS
> > ftp_passive on
> >
> > dns_children 5
> >
> > refresh_pattern . 5 20% 4000
> >
> > http_access allow All
> >
> > Any help will be greatly appreciated... !
> >
> > Bye,
> >
> > Richard.
> >
> *************************************************************************
>
> Ce message et toutes les pieces jointes (ci-apres le "message") sont
> confidentiels et etablis a l'intention exclusive de ses destinataires.
> Toute utilisation ou diffusion non autorisee est interdite.
> Tout message electronique est susceptible d'alteration.
> La SOCIETE GENERALE et ses filiales declinent toute responsabilite au
titre de ce message s'il a ete altere, deforme ou falsifie.
>
> ********
>
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> E-mails are susceptible to alteration.
> Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall
be liable for the message if altered, changed or falsified.
>
> *************************************************************************

*************************************************************************

Ce message et toutes les pièces jointes (ci-après le "message") sont
confidentiels et établis à l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisée est interdite.
Tout message électronique est susceptible d'altération.
La SOCIETE GENERALE et ses filiales déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.

                                ********

This message and any attachments (the "message") are confidential and
intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
E-mails are susceptible to alteration.
Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.

*************************************************************************
Received on Thu Aug 30 2001 - 04:02:34 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:01:57 MST