Re: [squid-users] squid 3.2.0.5 smp scaling issues

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sun, 12 Jun 2011 19:54:10 +1200

On 12/06/11 18:46, Jenny Lee wrote:
>
> On Sat, Jun 11, 2011 at 9:40 PM, Jenny Lee<bodycare_5_at_live.com> wrote:
>
> I like to know how you are able to do>13000 requests/sec.
> tcp_fin_timeout is 60 seconds default on all *NIXes and available ephemeral port range is 64K.
> I can't do more than 1K requests/sec even with tcp_tw_reuse/tcp_tw_recycle with ab. I get commBind errors due to connections in TIME_WAIT.
> Any tuning options suggested for RHEL6 x64?
> Jenny
>
> I would have a concern using both those at the same time. reuse and recycle. Reuse a socket, but recycle it, I've seen issues when testing my own linux distro's with both of these settings. Right or wrong that was my experience.
> fin_timeout, if you have a good connection, there should be no reason that a system takes 60 seconds to send out a fin. Cut that in half, if not by 2/3's
> And what is your limitation at 1K requests/sec, load (if so look at I/O) Network saturation? Maybe I missed an earlier thread and I too would tilt my head at 13K requests sec!
> Tory
> ---
>
>
> As I mentioned, my limitation is the ephemeral ports tied up with TIME_WAIT. TIME_WAIT issue is a known factor when you are doing testing.
>
> When you are tuning, you apply options one at a time. tw_reuse/tc_recycle were not used togeter and I had 10 sec fin_timeout which made no difference.
>
> Jenny
>
>
> nb: i still dont know how to do indenting/quoting with this hotmail... after 10 years.
>

Couple of thing to note.
  Firstly that this was an ab (apache bench) reported figure. It
calculates the software limitation based on speed of transactions done.
Not necessarily accounting for things like TIME_WAIT. Particularly if it
was extrapolated from say, 50K requests, which would not hit that OS limit.

He also mentioned using a "local IP address". If that was on the lo
interface. It would not be subject to things like TIME_WAIT or RTT lag.

The test was also specific to the very long lists of non-matching regex
ACL he apparently used. Once those were eliminated the test showed much
faster numbers, but similar worker pattern.

Overall, useful info for us regarding worker load sharing. And a bit of
a warning for people writing long lists of regex ACL. But the ACL issue
was not really surprising.

HTH

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.8 and 3.1.12.2
Received on Sun Jun 12 2011 - 07:54:20 MDT

This archive was generated by hypermail 2.2.0 : Sun Jun 12 2011 - 12:00:02 MDT