httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bing Swen" <>
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/
Date Sun, 21 Sep 2008 06:17:04 GMT
"Paul Querna" <> wrote on  2008-9-21 4:21

> Graham Leggett wrote:
>>> I know there are likely huge problems with this, but I would like to see 
>>> how far
>>> we can push the Event MPM, figure out what to do better, if there is 
>>> anything, and then really dive into the 3.0 development before 
>>> ApacheCon.
>> How difficult would this be to support in the other MPMs?
> Windows, Worker MPM and the similar threaded MPMs could do it easily.
> But, IMO, I want to eliminate all of the MPMs for 2.4/3.0.
> I believe the MPMs as they are designed right now, are both a layer of 
> portability, and a module that defines behavior or the model.
> Basically, one MPM to rule them all, with a configuration directive that 
> can make it act like prefork or the event MPMs.

Currently the role that MPMs play is to map a connection (with many 
requests, by HTTP/1.1) to a worker (a thread or process). But an optimal 
network i/o model needs a layer that maps a *request* to a thread, so that a 
worker thread (or process) will not have to be tied up entirely with a 
single connection during the whole life time of the connection. Instead, a 
worker can be scheduled to handle different connections, which helps both 
reducing the number of workers and the performance of request handling 
(especially on slow connections).

Such a layer should unify the upper interface of Event driven 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.

I hope that this would be one of the best features that 2.4+ will bring to 
us, as finally it will support any optimal i/o model on various platforms, 
and answer the doubts on Apache performance once and forever.

School of EE & CS,
Peking University,
Beijing 100871

View raw message