[tlug] Re: [RFC] Outline of the fast HTTP talk

[Curt Sampson <cjs@example.com>]

On 2008-11-03 18:56 +0000 (Mon), John Fremlin wrote:

> > As well: we gave up on ab quite a while ago, and use httperf[1] for
> > benchmarking. 
> 
> Why?

Because ab, at least the last time I used it, automatically rate-limited
itself to what the web server could handle.

If it still tells you how many requests per second the server can
handle, rather than you telling it how many to submit, it's still got
the same problem.

> > Httperf ... usually [runs] out of file descriptors long before
> > it's generated the kind of load a modern machine is capable of
> > generating.
> 
> Which is why it is useless for this. . .

I would disagree. That httperf does not slow down when the web server
does makes it exceedingly useful, actually. My major interest is not
just in how many requests per second a server can handle, but what
happens when it gets more than that. You'd be surprised at how many
systems, rather than degrading gracefully, collapse catastrophically.

I may not have given the right impression above, by the way. When I
said, "the kind of load a modern machine is capable of generating," I
meant the kind of load a good test program, given enough IP addresses
and OS support for what it's doing, is capable of generating. This is
guaranteed to bring any web server running on similar hardware to its
knees, even ones like yours serving only dynamic requests with little
computation, which are about the cheapest requests you can serve. (Yes,
they're considerably cheaper than requests for static files.)

> I get about 2k requests per second on one core of my laptop with the
> following mongrel script....
> 
> Are you in that ballpark? 

Well, I've not benchmarked recently, but last time I checked, we were
handling more than 500 requests per second on a 700 MHz Pentium II, so
I'd say, yes we certainly are. Probably, given that on a multi-core
machine we can distribute the load amongst multiple back-ends, we're
faster. (Or does mongrel have the capability to use multiple processes?)

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com