Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/

[Paul Querna <ch...@force-elite.com>]

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.

This makes all of the Unix ones very messy, with lots of copied code. 
Just look at Prefork, Worker, Event, Leader, Perchild -- they all have 
huge swaths of copied code.  And at their cores their behavior 
differences could just be runtime decisions.

I believe that at a minimum on the Unix side, and hopefully Win32 too, 
they should all be replaced with a single MPM, that has a  configurable 
behavior, and uses APR as much as possible, with only a few small ifdefs 
for portability.

Basically, one MPM to rule them all, with a configuration directive that 
can make it act like prefork or the event MPMs.

-Paul

Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/

[Jim Jagielski <ji...@jaguNET.com>]

On Sep 22, 2008, at 11:51 AM, Paul Querna wrote:
>
> 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.
>

Agreed. We're not talking, imo, about increasing performance. We're
talking increasing efficiency.

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

++1...

Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/

[Paul Querna <ch...@force-elite.com>]

Akins, Brian wrote:
> On 9/21/08 2:17 AM, "Bing Swen" <bs...@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

Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/

[Issac Goldstand <ma...@beamartyr.net>]

Akins, Brian wrote:
> On 9/21/08 2:17 AM, "Bing Swen" <bs...@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).
> 
> 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.
> 
> 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.
> 

Devil's advocate or not, the point is valid IMO.  We can (and likely
will) have loads of fun reworking everything, but I'm +1 with Brian here.

  Issac

Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/

[Graham Leggett <mi...@sharp.fm>]

Akins, Brian wrote:

> 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.

I think the risk of being extremely disappointed is a real risk, but I 
don't think it is a reason not to give it a try.

Perhaps a suitable compromise is to say this:

- Some people want to try to come up with a purely event driven model 
that requires changing the MPM interface as necessary. Who knows, it 
might give performance gains too!

- Some people want to keep an MPM that implements the worker model, 
because we know it works to an acceptable level.

If we can achieve both at once, that will be ideal.

> (Disclaimer: yes, I'm partially playing devil's advocate here.)

Wearing the hat of someone who likes to try out new stuff, from time to 
time you hit a dead end within the design of the server that makes it 
either hard to or impossible to achieve something new.

A shake up of the core is likely to remove some of these barriers, which 
in turn means that avenues open up that up till now have been dead ends, 
which makes the development interesting again.

I think the second-from-worst case scenario is that Paul and others end 
up exploring some cool ideas and they don't work, and then the fun was 
in the exploring of the new ideas, so nothing is really lost. The best 
case scenario is obviously that some cool ideas are explored and they do 
work. The worst case scenario is that people do nothing.

Regards,
Graham
--

Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/

["Akins, Brian" <Br...@turner.com>]

On 9/21/08 2:17 AM, "Bing Swen" <bs...@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).

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.

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.


(Disclaimer: yes, I'm partially playing devil's advocate here.)


-- 
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies

Re: Future direction of MPMs, was Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/

[Bing Swen <bs...@pku.edu.cn>]

"Paul Querna" <ch...@force-elite.com> 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.

Bing
----
School of EE & CS,
Peking University,
Beijing 100871