Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Thu, Oct 30, 2008 at 6:06 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> I tend to agree... as long as the architectural design doesn't
> prevent people from creating (or keeping) MPMs, then this is all
> good. Believe it or not, as people on the front-lines of handling
> Apache setup and support for organizations can attest to, MPMs are a
> valued feature.

I disagree.  It's incredibly confusing to have compile-time
definitions and inability to adjust them at run-time.

I'd prefer that we remove all MPMs and teach whatever remains to be
able to emulate prefork (multiple-process/single-thread) or worker
(multiple-process/multiple-thread) at run-time.

My $.02.  -- justin

AW: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

["Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>]

 

> -----Ursprüngliche Nachricht-----
> Von: Graham Leggett 
> Gesendet: Dienstag, 4. November 2008 18:21
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r708462 - in 
> /httpd/httpd/trunk/server/mpm: ./ simple/
> 
> Paul Querna wrote:
> 
> > Its trunk, it better be unstable or we are doing something wrong.
> > 
> > Thats why I think we should delete prefork, worker, event, 
> threadpool, 
> > perchild, and leader MPMs.
> 
> Since when was instability a design goal of ours? :)
> 
> When simple proves itself better than worker and prefork, +1 
> to having 
> them removed. But only when simple has proved itself better first.

+1 to this. New things have to prove themselves before we finally dump
older things.

Regards

Rüdiger

Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

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

Paul Querna wrote:

> Its trunk, it better be unstable or we are doing something wrong.
> 
> Thats why I think we should delete prefork, worker, event, threadpool, 
> perchild, and leader MPMs.

Since when was instability a design goal of ours? :)

When simple proves itself better than worker and prefork, +1 to having 
them removed. But only when simple has proved itself better first.

Regards,
Graham
--

Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

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

On Nov 4, 2008, at 12:15 PM, Paul Querna wrote:

> Graham Leggett wrote:
>> Justin Erenkrantz wrote:
>>> I think MPMs are a design mis-feature.  The fact that the same
>>> directive value can be (and is!) interpreted in non-uniform ways by
>>> different MPMs bugs me to no end.  -- justin
>> That is a flaw in the MPMs themselves (overloading a term is evil I  
>> agree), but not in the MPM concept as a whole.
>> The fact we have MPMs at all gives us the power to develop  
>> something like the simple MPM alongside existing stable MPMs,  
>> without being forced to endure a period of instability where the  
>> server doesn't work at all.
>
> Its trunk, it better be unstable or we are doing something wrong.
>
> Thats why I think we should delete prefork, worker, event,  
> threadpool, perchild, and leader MPMs.
>

Ummm... right now, trunk is the source for backports to
2.2.x.... Also, there are potential backports for these MPMs in
trunk that are not in 2.2.x.... So, if we decide, we either need
to branch off trunk to 2.2-dev and then delete, or branch off
trunk to httpd-nola and delete on *that* branch.

Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

[Nick Kew <ni...@webthing.com>]

William A. Rowe, Jr. wrote:

> What about perchild?  No answer, but removing it at this instant doesn't
> leave it glaring in our face that this problem set has not been solved.

Making unixd a module is the first step to removing the need for
perchild.  It should cease to need an MPM, and work with a new
conventional module under arch/unix instead.

At least, that's the general idea.

-- 
Nick Kew

Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Paul Querna wrote:
> Graham Leggett wrote:
>> Justin Erenkrantz wrote:
>>
>>> I think MPMs are a design mis-feature.  The fact that the same
>>> directive value can be (and is!) interpreted in non-uniform ways by
>>> different MPMs bugs me to no end.  -- justin
>>
>> That is a flaw in the MPMs themselves (overloading a term is evil I
>> agree), but not in the MPM concept as a whole.
>>
>> The fact we have MPMs at all gives us the power to develop something
>> like the simple MPM alongside existing stable MPMs, without being
>> forced to endure a period of instability where the server doesn't work
>> at all.

+++1

> Its trunk, it better be unstable or we are doing something wrong.

Don't worry, if you accidentally commit some rock-solid code, we'll still
forgive you :)

> Thats why I think we should delete prefork, worker, event, threadpool,
> perchild, and leader MPMs.

-1 to worker, prefork.  As far as event, leader, threadpool, they seem to
be proofs of concept realized in Simple (yes? no?) and should be svn rm'ed.

What about perchild?  No answer, but removing it at this instant doesn't
leave it glaring in our face that this problem set has not been solved.

Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

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

Graham Leggett wrote:
> Justin Erenkrantz wrote:
> 
>> I think MPMs are a design mis-feature.  The fact that the same
>> directive value can be (and is!) interpreted in non-uniform ways by
>> different MPMs bugs me to no end.  -- justin
> 
> That is a flaw in the MPMs themselves (overloading a term is evil I 
> agree), but not in the MPM concept as a whole.
> 
> The fact we have MPMs at all gives us the power to develop something 
> like the simple MPM alongside existing stable MPMs, without being forced 
> to endure a period of instability where the server doesn't work at all.

Its trunk, it better be unstable or we are doing something wrong.

Thats why I think we should delete prefork, worker, event, threadpool, 
perchild, and leader MPMs.

Thanks,

-Paul

Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

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

Justin Erenkrantz wrote:

> I think MPMs are a design mis-feature.  The fact that the same
> directive value can be (and is!) interpreted in non-uniform ways by
> different MPMs bugs me to no end.  -- justin

That is a flaw in the MPMs themselves (overloading a term is evil I 
agree), but not in the MPM concept as a whole.

The fact we have MPMs at all gives us the power to develop something 
like the simple MPM alongside existing stable MPMs, without being forced 
to endure a period of instability where the server doesn't work at all.

It also allows us to support newer OS features on modern systems, 
without being forced to ignore those features because legacy platform X 
doesn't support it. Legacy platform X can carry on using prefork (or 
whatever).

Regards,
Graham
--

Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Mon, Nov 3, 2008 at 11:23 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> You miss my point. If we just have one MPM, and make it
> such that other MPMs are at a significant advantage, then
> why even have MPMs? Hardcode in simple and be done.

(Assume you may have meant 'disadvantage'?)

> In any case, we can pretty much do that with Worker now,
> as well as Simple...

I think MPMs are a design mis-feature.  The fact that the same
directive value can be (and is!) interpreted in non-uniform ways by
different MPMs bugs me to no end.  -- justin

Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

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

On Nov 2, 2008, at 1:04 PM, Justin Erenkrantz wrote:

> On Thu, Oct 30, 2008 at 6:06 AM, Jim Jagielski <ji...@jagunet.com>  
> wrote:
>> I tend to agree... as long as the architectural design doesn't
>> prevent people from creating (or keeping) MPMs, then this is all
>> good. Believe it or not, as people on the front-lines of handling
>> Apache setup and support for organizations can attest to, MPMs are a
>> valued feature.
>
> I disagree.  It's incredibly confusing to have compile-time
> definitions and inability to adjust them at run-time.
>
> I'd prefer that we remove all MPMs and teach whatever remains to be
> able to emulate prefork (multiple-process/single-thread) or worker
> (multiple-process/multiple-thread) at run-time.
>

You miss my point. If we just have one MPM, and make it
such that other MPMs are at a significant advantage, then
why even have MPMs? Hardcode in simple and be done.

In any case, we can pretty much do that with Worker now,
as well as Simple...

Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Paul Querna wrote:
> 
>> We aren't there.  I don't care about prefork, if it isn't threaded there
>> is no point, but simple isn't the answer.  Because it's a static pool
>> of threads, it's no different than win32, but win32 really screams for
>> a resizeable thread pool for developer's installations and such (varies
>> between very small footprint and a modest number of connections).
> 
> Then improve the threadpool code in apr-util, the simple mpm itself has
> very little to do with the thread pooling implementation:

You miss my point though.  Sure - we can invest 100% effort into simple,
and within months demonstrate that all other mpms are inferior.  At that
point we deprecate and make 'simple' the default.  Next release, svn rm
those ancient sources.  Great!

It just doesn't seem to be worth forcing this unless there is a measurable
benefit to cutting out or rearranging the mpm hooks.  And if there is, then
maybe they just need refactoring (?)

I'm all over the idea of calling all old mpm's retired.  Just didn't see a
reason to svn rm the code until 'simple' is proven in the wild.

Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

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

William A. Rowe, Jr. wrote:
> Justin Erenkrantz wrote:
>> I'd prefer that we remove all MPMs and teach whatever remains to be
>> able to emulate prefork (multiple-process/single-thread) or worker
>> (multiple-process/multiple-thread) at run-time.
> 
> I suspect we are still a ways away from this.  If we can make the point
> that there's a obvious one-and-only mpm, then yes, maybe it's time.

On unix, I think we are much closer than you think:
SimpleThreadCount 1
SimpleProcCount 200

Would behave very similar to prefork does today. (and we can make some 
further optimizations when threadCount == 1, but those are optimizations 
to be done later imo).


> We aren't there.  I don't care about prefork, if it isn't threaded there
> is no point, but simple isn't the answer.  Because it's a static pool
> of threads, it's no different than win32, but win32 really screams for
> a resizeable thread pool for developer's installations and such (varies
> between very small footprint and a modest number of connections).

Then improve the threadpool code in apr-util, the simple mpm itself has 
very little to do with the thread pooling implementation:

http://apr.apache.org/docs/apr-util/1.3/group___a_p_r___util___t_p.html

It has the start number and can spawn more -- but I don't think it 
actively reaps idle threads.

Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Justin Erenkrantz wrote:
> 
> I'd prefer that we remove all MPMs and teach whatever remains to be
> able to emulate prefork (multiple-process/single-thread) or worker
> (multiple-process/multiple-thread) at run-time.

I suspect we are still a ways away from this.  If we can make the point
that there's a obvious one-and-only mpm, then yes, maybe it's time.

We aren't there.  I don't care about prefork, if it isn't threaded there
is no point, but simple isn't the answer.  Because it's a static pool
of threads, it's no different than win32, but win32 really screams for
a resizeable thread pool for developer's installations and such (varies
between very small footprint and a modest number of connections).

We'll truly stall if we begin the "one right mpm" war.  What we can do
is to make the mpm itself fairly innocuous, and move out some stuff from
the mpm to modules or core (e.g. like the new arch/unix/mod_unixd!!!)
That is measureable progress :)