---------------------------------------- > Date: Sun, 12 Jun 2011 19:54:10 +1200 > From: squid3@xxxxxxxxxxxxx > To: squid-users@xxxxxxxxxxxxxxx > Subject: Re: squid 3.2.0.5 smp scaling issues > > On 12/06/11 18:46, Jenny Lee wrote: > > > > On Sat, Jun 11, 2011 at 9:40 PM, Jenny Lee 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. Ab accounts for 200-OK responses and TIME_WAITS cause squid to issue 500. Of course if you send in 50K it would not be subject to this but I usually send couple 10+ million to simulate load at least for a while. > 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. When I was running my benches on loopback, I had tons of TIME_WAITS for 127.0.0.1 and squid would bail out with: "commBind: Cannot bind socket..." Of course, I might be doing things wrong. I am interested in what to optimize on RHEL6 OS level to achieve higher requests per second. Jenny
