Colm MacCarthaigh wrote:
On Fri, Sep 09, 2005 at 04:18:34PM -0400, Bill Stoddard wrote:
I guess for some definition of "much" I am not suprised. I would expect the
event MPM to consume more CPU than worker under 'low' workloads (low number
of concurrent clients) because it's making more system calls to do the same
amount of work. Event should start to show benefits as the number of
concurrent connections into the server goes up. That's what I would expect
anyway; no idea if the event MPM is sufficiently refined to show any
benefit at any workload.
I definitely see speed improvements using the event MPM, probably due to
the lack of an Accept Mutex. I have to get around to hacking the worker
MPM to see if that's what it is.
As part of my recent async R&D, I hacked a copy of the leader/followers MPM
to work with a single, central pollset (like event). It wasn't anywhere
near production
quality--I never got around to implementing tmeouts, for example--but it
was faster
than worker in non-real-world testing (client and server talking to each
other over
Gigabit ethernet.)
This weekend, when I have time to do some more httpd work, I'll do a more
robust hack of the leader MPM within the async-dev branch so that it's
available for other people to test.
Brian
