Fwd: [httperf] Re: Connection rate is very low
vikash.kumar at oneconvergence.com
Fri Oct 26 20:27:36 PDT 2012
---------- Forwarded message ----------
From: Vikash Kumar <vikash.kumar at oneconvergence.com>
Date: Thu, Oct 25, 2012 at 10:40 PM
Subject: Re: [httperf] Re: Connection rate is very low
To: Tim Terrill <TTerrill at synacor.com>
Cc: Raoufehsadat Hashemian <raoofeh.h at gmail.com>, Rick Jones <
rick.jones2 at hp.com>, "httperf at linux.hpl.hp.com" <httperf at linux.hpl.hp.com>
I am able to achieve around 17K connection/sec (reply rate is same)
for 5 million total number of connections with three node setup with
Haproxy is running on third m/c with 1G intel card.
Already told, Intel back-to-back(without involvement of *haproxy and
3rd m/c*) scales up to 32K connection/sec. This can be because of switching
done by Haproxy and may be h/w limitation. Can we improve performance? If
yes than how?
There are three issues that I want to discuss:
*First issue: *My experiments are done with three node setup and
switching is done by linux bridge. When the same tests are done with
installing *openvswitch-1.4.0* and *Haproxy *running on ovs bridge, the
performance drops to *3K *conn/sec. Unable to find out the reason.
*Second Issue: *When I installed *KVM on Haproxy host m/c* (just
installation no use), the httperf performance dropped for same test to 12K
reply/sec from 17K reply/sec. Unable to figure out , why and how to
overcome this behavior? However dmesg of Haproxy of hosst m/c shows TCP
SYN flooding. Can it be a cause of performance degradation?
*Third Issue: *I am getting in the dmesg of server and haproxy host the
following message "*Possible TCP SYN flooding : dropping pacckets".* Victor
suggested to disable TCP syn cookies but it also didn't helped much and
leads to some performance degradation. How to stop this?
On Tue, Oct 23, 2012 at 11:47 PM, Tim Terrill <TTerrill at synacor.com> wrote:
> Hi Raoufeh,
> So you're saying that you ran httperf (latest version 0.9.0) multiple
> times on a single server and were able to use more than 65k ports? If
> that's the case, that's good news. I guess we don't have to make any
> httperf changes then!
> I didn't see the tw_reuse=1 discussion…when was it? I joined a week or
> so ago.
> From: Raoufehsadat Hashemian <raoofeh.h at gmail.com>
> Date: Tuesday, October 23, 2012 2:01 PM
> To: Tim Terrill <tterrill at synacor.com>
> Cc: Rick Jones <rick.jones2 at hp.com>, "httperf at linux.hpl.hp.com" <
> httperf at linux.hpl.hp.com>, Vikash Kumar <vikash.kumar at oneconvergence.com>
> Subject: Re: [httperf] Re: Connection rate is very low
> Hi Tim,
> This actually helps a lot by reducing the testbed complexity and required
> resources. I previously ran tests with up to 6 instances of httperf on an 8
> core server, and it was successful (unless they are not in core 0, they are
> fine). Having those optimizations discussed in this thread (e.g.
> tw_reuse=1, max file descriptors and maximum ports) in place, I was able to
> emulate 6000 users of SPECWeb 2005. (maybe even more number of users was
> possible if network bandwidth and other bottlenecks were not there).
> On Tue, Oct 23, 2012 at 11:15 AM, Tim Terrill <TTerrill at synacor.com>wrote:
>> Sounds like one great enhancement (and should be simple I'd think -- pass
>> in a parameter and use it in bind()?)Š
>> Is anyone actively maintaining httperf?
>> Since httperf is designed to eat up an entire core, I guess we'd want to
>> bring up N httperf instances (one per IP), where N == # cores on serverŠ
>> On 10/23/12 12:50 PM, "Rick Jones" <rick.jones2 at hp.com> wrote:
>> >On 10/23/2012 08:23 AM, Tim Terrill wrote:
>> >> Bottom line is: you must keep the number of used ports under the Max
>> >> (around 65k) in any given TIME_WAIT period of time.
>> >Per IPpair and well-known port triple.
>> >When enhancing the SPECweb96 (yes, the issue of TIME_WAIT reuse goes
>> >back a very long time...) code to make explicit bind() calls to use the
>> >range of 5000 to 65535 became insufficient, we further enhanced it to
>> >start using multiple client IP addresses. That is, it started calling
>> >bind() not just with INADDR_ANY and a port number but a specific IP
>> >address and a port number (cycling through the range), and it started
>> >using more than one IP address.
>> >Just prior to that, we simply used multiple load generators/clients and
>> >got additional IP addresses involved that way. But it led to very
>> >under-utilized load generators and a higher cost of benchmarking. Thus,
>> >using multiple IP addresses on the load generators.
>> >happy benchmarking,
>> >rick jones
>> httperf mailing list
>> httperf at linux.hpl.hp.com
> Raoufehsadat Hashemian
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the httperf