Nicely done. Have you done any benchmarking to see if this improved
performance as one would expect? Would it be much more work to use true
async IO instead of non blocking IO and polling? What about doing the
same for reads, as well as writes?
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. Once an entire response has been
generated and passed to the output filter chain, the MPM's
poller/listener thread watches the connection for writability
events. When the connection becomes writable, the poller
thread sends it to one of the worker threads, which writes
some more output.
At this point, the event-handling code is ready for testing and
review by other developers.
The main changes on the async-dev branch (compared
to the 2.3-dev trunk) are:
1. ap_core_output_filter: rewrite to do nonblocking writes
whenever possible.
2. core, http module, and mod_logio: removed the generation
of flush buckets where possible.
3. request cleanup and logging: the logger phase and
subsequent destruction of the request's pool are now
triggered by the destruction of an End-Of-Request
bucket in the core output filter.
4. event MPM: asynchronous handling of CONN_STATE_WRITE_COMPLETION.
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 main pollset in the Event MPM currently is sized to
hold up to one socket descriptor per worker thread. With
asynchronous keepalives and write completion, the pollset
should accommodate many descriptors per thread.
- 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.
- 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 scoreboard probably needs a redesign.
- It may be valuable to have a separate thread pool to
run handlers that do arbitrarily lengthy processing, such
as mod_perl and mod_php.
Brian
