Squid 3.2 performance question

From: Alexander Komyagin <komyagin_at_altell.ru>
Date: Tue, 13 Mar 2012 13:14:07 +0400

Hello. We're now trying to give a chance to the new Squid 3.2 on our
server, mainly because of it's SMP feature. But our tests are showing
that 3.2 (3.2.0.14 and 3.2.0.16 were tested) performance is noticeably
lower than 3.1 (3.1.15).

We're using "httperf --client=0/1 --hog --server x.x.x.x --rate=100
--num-conns=1000 --timeout=5 --num-calls=10" for testing. And for 3.2
it's showing about 140 client timeouts (from 1000), while for 3.1 there
are no errors at all.

Different workers numbers were checked (1,2,4), but results are still
the same -- completely unchanged -- which is rather _strange_, since as
far as I know (by squid website and source browsing), in our
configuration workers shall NOT share anything but one listening socket
(y.y.y.y:3128).
More than that, CPU use is _only_ about 20% per worker (2 CPU's - 2
workers), vmstat reports no high memory consumption and iostat reports
0% on iowait.

Also according to logs, that clients timeouts are caused by some of new
connections not being spotted and accepted as well (not gone through
doAccept() routine from TcpAcceptor.cc).

Note that we're building squid against ulibc, so some differences with
glibc may take part. Also squid cache is disabled for now and squid is
configured as transparent proxy (config file attached). Config options
are:'--build=x86_64-linux' '--host=x86_64-altell-linux-uclibc'
'--target=x86_64-altell-linux-uclibc' '--prefix=/usr'
'--exec_prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--libexecdir=/usr/libexec' '--datadir=/usr/share' '--sysconfdir=/etc'
'--sharedstatedir=/com' '--localstatedir=/var' '--libdir=/usr/lib'
'--includedir=/usr/include' '--oldincludedir=/usr/include'
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--disable-epoll'
'--disable-nls' '--enable-ssl' '--enable-auth-digest=LDAP'
'--enable-auth-basic=LDAP' '--enable-epoll' '--enable-icap-client'
'--with-dl' '--enable-linux-netfilter'
'--disable-negotiate-auth-helpers' '--with-krb5-config=no'
'--enable-external-acl-helpers=wbinfo_group' '--enable-auth'
'--enable-auth-ntlm=smb_lm,fake'

To check that workers share the listening socket in a proper way and
principally can deal with all the connections, I have modified
parseHttpRequest() function for one kid to return Method-Not-Allowed for
all requests. That way all 1000 connections were successfully
established, with more than 800 of them refused due to this modification
(which is OK).

So it seems to me that either Squid kid's share some resources while
processing client requests, or I am completely missing something
important.

Squid 3.2 can be quite useful for us (db logging, etc.), and maybe ulibc
or squid needs a patch to make things better for using squid with ulibc.

-- 
Best wishes,
Alexander Komyagin

acl net src all
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT

cache_log /var/log/squid/cache.log

http_access allow manager net
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access allow net
http_access deny all

workers 2
cache deny all
access_log none

cache_store_log none

http_port y.y.y.y:3128 transparent

forwarded_for off

cache_mgr webmaster
visible_hostname Altell_Squid
Received on Wed Mar 14 2012 - 00:14:58 MDT

This archive was generated by hypermail 2.2.0 : Thu Mar 29 2012 - 12:00:11 MDT