httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bswen" <bs...@pku.edu.cn>
Subject RE: 3.0, the 2011 thread.
Date Thu, 16 Jun 2011 09:18:10 GMT
Paul Querna [mailto:paul@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




Mime
View raw message