httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: async write completion prototype
Date Tue, 11 Oct 2005 05:09:14 GMT
On Oct 10, 2005, at 12:01 AM, Paul Querna wrote:

> 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.
> If the content has already been generated, why add the overhead of  
> the context switch/sending to another thread?  Can't the same event  
> thread do a non-blocking write?
> Once it finishes writing, then yes, we do require a context-switch  
> to another thread to do logging/cleanup.
> I am mostly thinking about downloading a 1 gig file with the  
> current pattern against a slow client.  A non-blocking write might  
> only do ~64k at a time, and causing 1 gig/64k context switches,  
> which seems less than optimal.

If I had to choose, I'd rather do the context switches than devote a
thread (and the associated stack space) to the connection until
the writes are finished--especially if the server is delivering a
thousand 1GB files to slow clients concurrently.

However, it's probably possible to have _both_ a high ratio
of connections to threads (for scalability) and a low ratio of
context switches to megabytes delivered (for efficiency).
The Event MPM currently has to do a lot of context switching
because it detects events in one thread and processes them
in another.  If we add async write completion to the
Leader/Followers MPM (or incorporate a leader/follower
thread model into Event), it should reduce the context
switches considerably.

> ...
>> - 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 pollset is auto-resizable.  That number is just the maximum  
> number of events that will ever be returned by a single call to  
> _poll().  This number if perfect for the number of threads, since  
> we can never dispatch to more than the number of threads we have...

Ah, thanks.  I missed that key point.  It makes more sense now.


View raw message