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 KomyaginReceived 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