Paul Querna wrote:
Brian Akins wrote:
Paul Querna wrote:
[...]
Have you tried it with higher number of clients -- i.e,. -c 1024?
Nope. I was already maxing out my 100mbit LAN at 25 clients. I don't have a good testing area for static content request benchmarking.
I am thinking of trying to find an old pentium I with PCI and putting a GigE card in it just for benchmarking.
How about modifying ab to add a delay of a second or two between successive read(2) calls
on the same connection (and limiting the max read size to a small value, to make sure each
response requires multiple reads)? The throughput numbers wouldn't be very impressive, of
course, but you'd be able to see how much memory and how many threads the Event MPM
uses in handling a real-world number of concurrent connections, compared to Worker.
The current patch does not spawn new threads on demand. You need to set "ThreadsPerChild 1200" to test that many clients. This is on my short list of things to change before committing the Event MPM to CVS.
This part seems surprising. What's the relationship between clients and threads in the
Event MPM--does it use a thread per connection?
I haven't had a chance to check out the Event MPM yet, but I'm planning to download it and
study the code later this week.
For what it's worth, I can think of at least one killer app for the Event MPM beyond keep-alive
handling: as an efficient (low memory & thread use per connection) connection multiplexer in
front of an inefficient (high memory & thread use per connection) appserver.
-Brian
