Brian Pane wrote:
On Oct 18, 2005, at 7:11 AM, Greg Ames wrote:
Brian Pane wrote:
I think one contributor to the event results is an issue that Paul
Querna
pointed out on #httpd-dev the other day: apr_pollset_remove runs in O(n)
time with n descriptors in the pollset.
thanks, I see it. yeah we are going to have to do something about that.
I just committed a change to the epoll version that eliminates the
O(n) loop--and the mutex operations and a bit of data structure
copying.
Awesome! I really like it, a very nice addition to apr_pollset. I will
try to update APR with KQueue support on Sunday.
The version of the Event MPM on the async-dev branch takes
advantage of this new feature. I'm seeing a ~5% increase in
throughput in a simple test setup (http_load on a client machine
driving ~200 concurrent connections over 1Gb/s ethernet to
Apache running on Linux 2.6).
If anybody with a more industrial-strength load testing setup
can try the async-dev version of the Event MPM with a few
thousand concurrent connections, I'm eager to hear whether
this new epoll code yields a useful speedup.
I agree, I have had problems in the past telling if any changes to the
Event MPM have good or bad performance implications. Some of it is best
guess, but it really would be nice to have a semi-reliable way to
benchmark it that included Keep Alive connections.
-Paul
