Paul Querna wrote:
Brian Akins 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.
I'd love to find one like this too. I sometimes use a 180 MHz Pentium Pro box. But it only has 160M of EDO memory which is hard to scrounge around here, and probably can't use modern hard drives effectively due to BIOS limitations.
How about modifying ab to add a delay of a second or two between successive read(2) calls
on the same connection
an excellent idea. Or maybe add a delay after any read if -k is in effect.
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?
one thread per connection with an active http request, plus the listener/event thread who owns all the connections in keepalive. I believe Paul is saying set ThreadsPerChild to 1200 to handle the worst case behavior - 100% of the connections are doing real work at some instant and none are in keepalive timeouts.
Greg
