httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
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 Mon, 22 Sep 2008 15:51:49 GMT
Akins, Brian wrote:
> On 9/21/08 2:17 AM, "Bing Swen" <bswen@pku.edu.cn> wrote:
> 
>> 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).
> 
> I still want to see this backed up with real world experience.  I know I
> keep repeating myself, but in the real world, we have never seen the
> supposed inherent performance problems in the worker model (1 connection = 1
> thread).

At $work, we just upgraded RAM in what is essentially web server 
machines, just because we are running worker MPM and expect lots of long 
lived connections.  It has a cost, and it isn't free.

> It sounds great to theorize about the wonders of a completely event driven
> or asynchronous model. However, it seems that this only nets real measurable
> performance gains is very simplistic benchmarks.


What I view happening in the event MPM today, and where I would like to 
go in 2.4, isn't a fully 'asynchronous model'.

It is much more of a hybrid, using threads (and processes) when running 
most code, but allowing requests to be moved to an event queue, waiting 
for IO, or a timer.

> I'm all for making httpd faster, scale better, etc.  I just don't want to be
> extremely disappointed if we rewrite it all and gain nothing but a more
> complicated model.  If we get great gains, wonderful, but I'd like to see
> some actually numbers before we all decided to rework the core.

No, in pure requests/second, there will not be a significant difference.

Today, a properly tuned apache httpd, with enough RAM, can keep up with 
the 'fastest' web servers of the day, like lighttpd.  Most of the 
benchmarks where we do badly, is when apache httpd is mis-configured, or 
running on extremely low RAM resources.

I think what we solve, is that with a slightly more async core and MPM 
structure, we can signfigantly reduce the memory required to service 
several thousand long lived connections.

Moving forward with a hybrid that lets you pull in async abilities when 
needed seems reasonable to me.....

-Paul




Mime
View raw message