Re: [squid-users] squid rproxy - heavy load test.. summarization..

From: Troels Arvin <[email protected]>
Date: Tue, 13 Nov 2001 19:46:48 +0100

On Tue, 13 Nov 2001 11:32:06 +0100, "Klavs Klavsen" <ktk@metropol.dk>
wrote:

> - Anything else I can do.. to increase the max req/sec, the
> max
> concurrent sessions, and the way it deals with Max loads?

How many file descriptors AKA file handles does your Squid have available?

Make sure that Squid has access to enough filehandles. This involves:

On the host where you compile squid:
-----------------------------------
Let's say you want to let Squid use 8192 file descriptors (in stead of
the default 1024 on Linux systems). With Red Hat Linux, this may mean
that you must

as root:
1. echo 8192 >/proc/sys/fs/file-max
2. put a line like this in /etc/security/limits.conf :
    YOURUSER soft nofile 8192
    YOURUSER hard nofile 8192
    (exchange YOURUSER with your login, perhaps "ktk")
3. alter /usr/include/bits/types.h so that __FD_SETSIZE
    is set to 8192 (line 98 the types.h my laptop system):
    #define __FD_SETSIZE 8192
    (this step is ugly; I wonder why the number of
    file-handles can't be explicitly configured when
    compiling squid - but it seems that __FD_SETSIZE
    is used in many different places in squid's source)

as your normal user:
4. ulimit -HSn 8192
5. compile squid with whatever optimizations/switches
    that you have found useful for performance. We use:
    --enable-removal-policies="heap,lru" \
    --enable-async-io \
    --enable-storeio="ufs,aufs,coss,diskd" \
    --disable-ident-lookups \
    --disable-wccp \
    --disable-snmp \
    --enable-poll \
    --enable-x-accelerator-vary

    (The last option is only available if you have
    used Henrik's Vary patch - and is maily relevant
    if you have server-side code responding differently
    to different browser models.)

On the hosts running squid:
--------------------------
1. install your newly compiled squid
2. echo 16384 >/proc/sys/fs/file-max
    (squid will probably not be the only daemon running,
    so we want to allow for more file-handles than the
    8192 which squid might consume)
3. Put a line like this in /etc/security/limits.conf
    squid soft nofile 8192
    squid hard nofile 8192
4. Put this in the init-script which starts squid:
    ulimit -HSn 8192
5. Put a line like this in squid.conf:
    max_open_disk_fds 8192
6. start squid

When your squid is running, use cacemgr.cgi to verify that Squid has
access to 8192 filehandles and not the default 1024. The relevant menu
item is "General Runtime Information", section "File descriptor usage
for squid", item "Maximum number of file descriptors".

About runtime configuration:
Some lines from our squid.conf:

cache_access_log /dev/null
cache_log /var/log/squid/cache.log
cache_store_log none
buffered_logs on
cache_dir aufs /var/spool/squid 2500 16 256
request_body_max_size 30 MB # max HTTP-upload
refresh_pattern 1 20% 5 ignore-reload
negative_ttl 0
range_offset_limit -1 KB
cache_mem 700 MB
memory_pools on # wonder if this is actually smart
max_open_disk_fds 8192
maximum_object_size 16384 KB
maximum_object_size_in_memory 2000 KB
store_avg_object_size 4 KB # check with cachemgr.cgi
cache_replacement_policy heap LFUDA
memory_replacement_policy heap LFUDA
half_closed_clients off

The above directives may not be _the_ way to configure/run squid (some
of the metioned steps may not be needed), but it works pretty well for
us: After the Airbus crash in New York, we didn't have major problems
other than a saturated uplink line and some network problems on our
internal LAN; we didn't have 900 requests/sec, though.

I package our Squids in custom RPMs and manage the patches and
configuration in CVS. I could send you some RPM-related files (stripped
from tv2.dk passwords, ACLs, etc.) if you're interested. Note, however,
that we don't use squid rproxy; we use Squid 2.4STABLE2 (with some
patches) on Red Hat Linux 7.x installations on 2GB RAM/dual CPU servers
placed behind a Cisco LocalDirector load balancer. Our Squids sit on the
same servers as our Apache daemons.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark
System administrator at TV 2/interaktiv
Received on Tue Nov 13 2001 - 11:47:08 MST

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