Re: RFC for a Perchild-like-MPM

[Enrico Weigelt <we...@metux.de>]

* Paul Querna <ch...@force-elite.com> wrote:

Hi,

> I have had an idea for replacing the perchild MPM boggling around inside 
> my head for awhile now.  This is an idea for a different architecture to 
> allowing different UIDs to serve httpd requests.  I am looking for all 
> feedback with my proposed approach.

Probably I've missing something, but I've never seen that perchild was 
ever really working. It is vulnerable for an simple ptrace-attac, and 
that's not just a bug, its fundamental misdesign. So its dead-born child.

We've done a complete redesign of an multiplexer-based MPM, but it seems
that no one's really interested in it here. We've supplied patches against
various httpd2 releases. 

    http://nibiru.borg.metux.de:7000/wiki.mpm/
    
Many folks are using it quite sucessfully in production environments and 
SuSE (*the* major distributor in middle Europe is already shipping it 
for quite a while). 

But here on httpd-dev it seems that no one's really interested it.
Instead of shipping our multiplexer mpm at least as 'experimental'
(remember: its already in production use for quite a long time),
there's still just the misdesigned perchild.

Am I the only one who wonders about that ?


<snip>
> First, we start with a concept I am calling 'Server Pools'.  Each pool 
> has specific limits.  These can include a maximum number of processes, 
> or other limits based on resource usage.  A root server pool can contain 
> other pools, or sub pools.
> (xxxx: perhaps 'server pools' is a bad word for this idea?)
<snip>
> Since you need the ability to spawn more processes on demand when none 
> exist, there will be a 'controller process' that manages all server 
> pools, killing or using fork() to spawn new pools.
In other words: improve the "mother" code of metuxmpm to allow more
detailed configuration. Currently we have no on-demand-spawning, but its 
planned and we have some concepts for that.

<snip>
> A frontend will parse the incoming request, and provide other services, 
> like input filters, output filters, and logging.  This frontend will 
logging of course, but why not filtering in the target UID ? 

> pass the request back to a server pool by asking the control process for 
> which server pool should service this request. 
bad idea. too slow. the frontend should know how to find the right 
processor child. if we also use statistical data for that, this can be
sent from the mother to the multiplexer.

<snip>
> If no server pool currently has any processes running, the control 
> process will spawn one or more.
Probably I misunderstood something in your pool concept, but shouldn't 
the pools be defined by the admin ? (ie. one pool per user ?)

<snip>
> I disagree with the concept of passing a client socket directly to the 
> back-end as perchild does. 
What's bad on this concept ? It performs very well.

<snip>
> I believe it would be better to write a protocol handler for AJP or another 
> binary type protocol and therefore, hopefully, faster for passing requests 
> to a backend server pool via Unix Daemon Sockets. By passing the socket 
> directly to the backend, we enter a hell related to input filters, keep 
> alive requests, and http 1.1 pipelining.  
#1: filters belong into the processor child. we can assume that headers
    can always be read without filters. 
#2: keep alive *could* be a conceptional problem, since its simply not 
    defined anywhere whether an persistent connection *may* carry requests
    to several vhosts. we did never see this (metuxmpm would shout very
    loud in this case) and it seems quite improbable that clients authors
    tend to bunch connections+requests together by IP instead of name.
    (of course it would be possible)

> I also believe that for most cases, an optimized AJP like protocol would 
You "believe" ... well there're folks who believe in little gray men from 
alpha centauri - so not a good argument ;-)
It can be easily proven, that its slower, since the machine has much more
to do, ie:
    + encapsulate the request
    + pass the (enc) request between processes
    + decapsulate the request
    + encapsulate the reply
    + pass the (enc) reply between processes
    + decapsulate the request

You probably could get some speedups by using shared memory, but its 
still notacibly slower than simply passing the connection itself.

<snip>
> What this Solves:
> - Keep Alive/Pipelining/SSL decoding.. etc. These are all handled by the 
> fontend.

AFAIK SSL/https is not suited for name based virtual hosting (what shall 
be the primary sense of this mpm). Also not a bug, but a design problem
of the https protocol. 

<snip>
> - PHP Support. The backends could be process or threaded, it doesn't 
> matter, but at the same time, the frontend could resemble the Event or 
> Worker MPM.
Already working in metuxmpm for a long time.

<snip>
> Thoughts:
> - Hacking a demo via mod_proxy
> - Is this a better design than perchild MPM?
evryting's better than perchild ;-)

<snip>
> In some ways, this is just a more automated mod_proxy w/ load balancing 
> that will auto-spawn your backend servers on demand.  
that's what makes it slow.



cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact@metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------

Re: metux MPM, was RFC for a Perchild-like-MPM

[Enrico Weigelt <we...@metux.de>]

* Paul Querna <ch...@force-elite.com> wrote:

<snip>
> I only see patches for 2.0.48 and .49.  Do you have something against 
> Subversion Trunk?  Have you tried it against 2.1 yet?
not yet. 
we all have very plenty time. the maillist is full of people, but 99.9% 
only lurking :(

<snip>
> Then be active on this mailing list, never stop pushing the code, and it 
> has a good chance of getting in.  Honestly, I haven't seen a concerted 
> effort to get metux mpm back into the mainline, but I welcome one.
Well, we had regular announces some time ago, but now everyone had 
become quite lazy due no response.

<snip>
> I cannot just take one of those patches from the website and commit it 
> to subversion.  What is the next step, I am not sure, but do not stop 
> pushing to get your code in.
You could apply the patch to a current release and look if it works.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact@metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------

metux MPM, was RFC for a Perchild-like-MPM

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

Enrico Weigelt wrote:
> We've done a complete redesign of an multiplexer-based MPM, but it seems
> that no one's really interested in it here. We've supplied patches against
> various httpd2 releases. 
> 

>     http://nibiru.borg.metux.de:7000/wiki.mpm/

I only see patches for 2.0.48 and .49.  Do you have something against 
Subversion Trunk?  Have you tried it against 2.1 yet?

> Many folks are using it quite sucessfully in production environments and 
> SuSE (*the* major distributor in middle Europe is already shipping it 
> for quite a while). 

Great.

> But here on httpd-dev it seems that no one's really interested it.
> Instead of shipping our multiplexer mpm at least as 'experimental'
> (remember: its already in production use for quite a long time),
> there's still just the misdesigned perchild.

Then be active on this mailing list, never stop pushing the code, and it 
  has a good chance of getting in.  Honestly, I haven't seen a concerted 
effort to get metux mpm back into the mainline, but I welcome one.

I cannot just take one of those patches from the website and commit it 
to subversion.  What is the next step, I am not sure, but do not stop 
pushing to get your code in.

-Paul