On 6/16/2011 4:18 AM, bswen wrote: > > I think the only major problem of httpd is its "one thread per connection" > I/O model. It's an inherently unscalable design. Httpd-3.0 will be > meaningless if it keeps on this i/o design.
That is no longer its design; it is now "one thread per request". Intra-connection mechanics are now handled in an event loop when using the event mpm, and this is worked well in real life. Some modules which manipulate the connection or make connection-scope assumptions about threading will be require the user to stay on worker or prefork, of course. Long lived requests still pose a challenge. > it's well possible to use only a very few threads (no. of CPU cores) to > handle tens of thousands of (slow) connections. > > An optimal network i/o model needs a scheduling layer that maps a *request* > (not a connection) to a thread, so a worker thread can be scheduled to handle > different connections, instead of being tied up entirely with a single > connection during the whole life time of the connection. We hope such a layer > should unify the upper interface of Event i/o, Windows i/o completion port, > and many other async i/o mechanisms. With luck and careful design, the > current filtered i/o chain and the module API can remain the same. > > That might be server as a good mark for the httpd-3.x releases?
