[httperf] Re: Connection rate is very low
raoofeh.h at gmail.com
Tue Oct 23 11:01:34 PDT 2012
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the httperf