Brian Pane wrote:
With the batch of commits I did this weekend, the Event MPM in
the async-dev Subversion branch now does write completion
in a nonblocking manner.
very cool!
There are several more things that need to be fixed in order
to make the asynchronous write completion useful in a
production release of httpd-2.x:
...
- The logic for starting more child processes, which Event
inherited from Worker, is based on assumptions about
the number of concurrent connections being equal to
the number of threads. These assumptions aren't valid
for a multiple-connections-per-thread MPM.
certainly the name MaxClients is wrong - it's really MaxWorkerThreads
for event. but the logic does a pretty good job of managing the threads
if you can get past the name.
- Similarly, there may be some changes needed in the
flow control logic that the listener thread uses to decide
whether it can do an accept.
the flow control I'm aware of is that ap_queue_info_wait_for_idler
blocks, therefore the listener temporarily quits accept()ing until
worker threads are available. clearly that is needed. the question is
should there be some other cap on the number of connections per process.
if we do a really good job of raising the connections per thread ratio
and continue to use ThreadsPerChild as the throttle, we will be bumping
against OS file descriptor per process limits more often. that sounds
kinda ugly, so I think we will want some kind of MaxConnectionsPerChild.
if the async write completions are moved to the listener thread as Paul
suggests, we might want another flow control change. there's no need to
reserve/block for a worker thread in that case.
- The scoreboard probably needs a redesign.
yep. Jeff T and I discussed this offline a while back. a scoreboard
slot per connection definately has some appeal.
...
my list:
- make it work with mod_ssl and http pipelining. this
http://mail-archives.apache.org/mod_mbox/httpd-dev/200411.mbox/[EMAIL PROTECTED]
fixes it in theory. my problem is testing/verifying it. if I knew how
to make mod_ssl's input filters stash data it shouldn't be too bad.
- event-ize lingering close. it eats up roughly the same number of
worker threads as synchronous writes for SPECweb99.
Greg
