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.
...
- 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...
- The scoreboard probably needs a redesign.
Yes.. it is completely unhelpful with the maximum number of connections being > number of threads. I suspect going forward there will be many other areas where this assumption is broken by the event mpm.
-Paul
