Re: Squid 3.2 performance question

On Tue, 2012-03-20 at 10:56 -0600, Alex Rousskov wrote:
> On 03/20/2012 06:14 AM, Alexander Komyagin wrote:
> >>>> By comparing oprofile results for 3.2 with and w/o RSBAC-Net, I can
> >>>> assume that RSBAC-Net subsystem performs some internal operations on
> >>>> list structures, which are indeed protected by locks - and this, in my
> >>>> point of view, may block simultaneous squid socket operations and affect
> >>>> performance.
>
> >> > Possible. We would not know.
>
> There are no simultaneous squid socket operations in no-daemon mode.
>
>
> > From RSBAC logs squid 3.2 produces much more operations on NETLINK RAW
> > ROUTE sockets than 3.1. Maybe performance differs due to some changes in
> > the Squid interception mechanism in 3.2?
>
> FWIW, I think it would be rather valuable for Squid and possibly RSBAC
> folks to figure this one out:
>
> 1) If Squid v3.2 in no-daemon mode is slower than v3.1, then we may want
> to change something in v3.2. In no-daemon mode, there are no shared
> accepting sockets so we cannot use them as an excuse for slowing things
> down. I recommend switching to forward proxying mode to eliminate or
> confirm interception as a suspect first.
>
> 2) If #1 is resolved but Squid v3.2 is still slower than v3.1 when
> multiple workers are used, then RSBAC folks may need to fix their stuff.
> I would not recommend working on this until #1 is resolved though.
>
>
> HTH,
>
> Alex.

Alex, I've already done it (#1). Though I hadn't figured out how to use
httperf with forward proxy, I used ab (Apache Benchmark), and it shows
that squid is about 1.5x faster when interception is off; also there are
much less NETLINK RAW ROUTE ops in RSBAC log. So interception may be our
first suspect.

On Tue, 2012-03-20 at 21:35 +0100, Henrik Nordström wrote:
> > Yep, looks like I have them in SYN_SENT for 5 secs and then they are
> > discarded (timeout for httperf is set for 5 secs).
>
> And what is seen on the server side?
>
> There is mainly two limits that may get hit with such results, not
> counting kernel bugs.
>
> a) Firewall connection tracking.
>
> b) Socket listen backlog queue.
>
>
> 'a' shows up in dmesg.
>
> not sure about 'b'.
>
>
> > > This RSBAC? http://www.rsbac.org/
> > >
> > > If so, which kernel version?
> >
> > This one. 2.6.35.10 SMP x86_64.
>
> With which version of the RBAC patch? RBAC 1.4.5 have issues according
> to rbac.org, and 2.6.35.10 is in the affected range. Now I do not think
> that issue affects socket operations but not 100% sure.

Henrik, there is nothing in dmesg, also it would be highly strange to exceed any limits
with 3.2.0.16, but stay cool with 3.1.

RSBAC is 1.4.5. Thanks, I checked that issue (regarding interception of the sys_open() call) on rsbac.org,
and I don't think it really matters, since still squid 3.1 works fine.

More than that, I made one more check and found out that Squid 3.2.0.7 seems unaffected by the problem, whatever it is.
According to httperf, it works slightly slower than 3.1, but all requests are served (10k/10k, while for 3.2.0.16
I have only 8k served). I'll try some more squid versions in between.

-- 
Best wishes,
Alexander Komyagin