Re: Squid 3.2 performance question

From: Alexander Komyagin <komyagin_at_altell.ru>
Date: Wed, 21 Mar 2012 20:45:47 +0400

OK, here are more results we got so far..

Squid 3.2.0.7 and 3.2.0.8 don't show any significant performance
downgrade in my configuration (however, without RSBAC-Net both run
slightly faster). But Squid 3.2.0.10 and 3.2.0.11 has that downgrade
just like 3.2.0.16.

Unfortunately 3.2.0.9 doesn't work well (only 150 replies for 1000
requests, and a lot of sockets left in TIME_WAIT - probably due to a
bug).

For "httperf --client=0/1 --hog --server x.x.x.x --rate=100
--num-conns=1000 --timeout=5 --num-calls=10" the results are:

Without RSBAC-Net:
          CONNS| REQS| REPLS|CONNS/s| REQS/s|REPLS/s|
All : 1000| 10000| 10000| 100| 999| 999|

With RSBAC-Net:
          CONNS| REQS| REPLS|CONNS/s| REQS/s|REPLS/s|
3.1 : 1000| 10000| 10000| 100| 999| 999|
3.2.0.7,8:1000| 10000| 10000| 93| 935| 935|
>3.2.0.10:1000| 8220| 8220| 67| 554| 554|
2 workers:1000| 8780| 8780| 65| 577| 577|

Also I checked that NAT Lookup request position doesn't matter (just to
be sure): I moved the call to Ip::Interceptor.NatLookup() from
connStateCreate() to oldAccept() for 3.2.0.8, but performance wasn't
affected by this change.

There is still the possibility that the problem was introduced earlier,
in <3.2.0.10 (note that 3.2.0.7 and 3.2.0.8 with RSBAC-Net work a little
bit slower than 3.1), but in >3.2.0.10 it exploded somehow.

I really want to find out what is exactly causing squid 3.2 to slow
down. Actually I can always try to debug RSBAC, but debugging kernel may
last forever (little possibility that I'll got some debug print like
"Warning: this may cause problems").

-- 
Best wishes,
Alexander Komyagin
Received on Wed Mar 21 2012 - 16:47:30 MDT

This archive was generated by hypermail 2.2.0 : Thu Mar 22 2012 - 12:00:06 MDT