[httperf] file descriptors

[Mark Nottingham]

I've compared against the select-based httperf against a few known  
servers, and the results seem equivalent.

The interesting thing is that at lower rates, CPU usage is high (but  
not >90%, as with select), but as they get higher, it dips pretty  
substantially (much < 50%) and then slowly ramps up again. This is  
useful, because you can tell when CPU on the client may become an  
issue...

I think we should get this out there ASAP. The only thing that needs  
to happen now is that configure should complain if it can't find  
libevent, I think, and the docs need to be updatd WRT CPU usage.

The biggest perf limit I've got now is that I can generate about 550  
*connections* a second; past that gets me a connection failed with  
unexpected error 99, which is ENOSTR (not a stream). This is Red Hat  
Linux. Any thoughts here? I see this with both select and libevent, so  
it's not the new code. It always happens around the same rate; it's  
not dependent upon how long the test has run, or the timeout  
(suggesting that it's not cumulative resource exhaustion a la  
ephemeral ports).

Cheers,






On 09/07/2008, at 8:42 AM, Adrian Chadd wrote:

> On Wed, Jul 09, 2008, Theodore Bullock wrote:
>
>>> Adrian Chadd wrote:
>>> (Noone's bothered trying it out? Its going to be a hell of a lot  
>>> faster
>>> than stock httperf..)
>
>> I will try it out this weekend.
>>
>> I have been working on a virtual machine with 256 mb of memory, so
>> things area ridiculously slow until I get my laptop repaired.
>
> Ok. Please let me know. I'd ideally like my work to be folded into
> the main httperf distribution.
>
>
>
> Adrian
>
> _______________________________________________
> httperf mailing list
> httperf at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/httperf/

--
Mark Nottingham       mnot at yahoo-inc.com