Paul Querna [mailto:p...@querna.org] sent on Thursday, June 16, 2011 6:02 AM > > I think we have all joked on and off about 3.0 for... well about 8 years now. > ... > The problem is our process model, and our module APIs. > > The Event MPM was a valiant effort in some ways, but mod_ssl and other > filters will always block > ... > libuv: Portable, fast, Network IO. (IOCP programming model, brought to Unix) > <https://github.com/joyent/libuv> > ...
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. As we discussed long time ago, (e.g., Sent: Sunday, September 21, 2008 2:17 PM Subject: Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/ Sent: Sunday, August 31, 2008 9:49 PM Subject: Re: [community] 2.3.0 alpha on October 1? ) 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? Regards, Bing