[squid-users] Squid network read()'s only 2k long?

From: <declanw_at_is.bbc.co.uk>
Date: Mon, 1 Nov 2010 15:00:21 +0000


I am poking a potential squid upgrade from squid 2 to 3.1.8 with a new
config, but it's added around 40% more CPU load, and I'm looking for

One thing I notice it doing when I truss is read()ing HTTP responses with
only a 2046 byte buffer, whereas squid2 used 24Kb. This is making for a lot of
unnecessary system calls and go-arounds in the main polling loop.

I went for a rummage in the code for the buffer size decisions, but got very
very lost in the OO abstractions very quickly. Can anyone point me at
anything I can tweak to fix this?

Besides that, I have a laaarge url_regexp file to process, and I was
wondering if there was any benefit to trying to break this regexp out to a
perl helper process (and if anyone has a precooked setup doing this I can

Beyond that, I assume, to get the most out of a multi-cpu system I should
be running one squid per CPU, which means I need more IP's and that they
can't share their memory or disk caches with each other directly, and I
would need to switch on HTCP to try and re-merge them?

While I'm musing here, is there any way to make an ACL construct that makes
a decision based on whether something is already cached? I have a lot of
heavy ACL's, and if something is cached, in my case, it will prove that it
has previously passed all the ACL's and I can just return the cached copy.

Build: Sun Solaris 9
PATH=~/sunstudio12.0/bin:$PATH ./configure CC=cc CXX=CC CFLAGS="-fast -xtarget=ultra3i -m64 -xipo" CXXFLAGS="-fast -xtarget=ultra3i -m64 -xipo" --enable-cache-digests --enable-removal-policies=lru,heap --enable-storeio=aufs,ufs --enable-devpoll

Tuney bits of Config:
htcp_port 0
icp_port 0
digest_generation off
quick_abort_min 0 KB
quick_abort_max 0 KB
read_ahead_gap 64 KB
store_avg_object_size 16 KB
read_timeout 5 minutes
request_timeout 30 seconds
persistent_request_timeout 30 seconds
pconn_timeout 3 seconds
cache_mem 512 MB
maximum_object_size_in_memory 64 KB
memory_replacement_policy heap GDSF
ignore_expect_100 on
client_db off

Grateful for any tips and pointers.

Received on Mon Nov 01 2010 - 15:00:32 MDT

This archive was generated by hypermail 2.2.0 : Tue Nov 02 2010 - 12:00:02 MDT