[httperf] Re: Connection rate is very low
vikash.kumar at oneconvergence.com
Thu Oct 25 10:10:11 PDT 2012
My apology for responding late. Thanks for your such a detailed
explanation. It helped. 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 u throw some light on this?
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 280
reply/sec from 17K reply/sec. Unable to figure out , why and how to
overcome this behaviour?
*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?
Any suggestion is very much appreciated.
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