httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: async write completion prototype
Date Tue, 11 Oct 2005 00:15:48 GMT
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

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.


View raw message