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