Paul Querna [mailto:[email protected]] 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
