Re: Single-threaded/non-blocking frontend and multi-threaded/processed backend

[Olaf van der Spek <ol...@gmail.com>]

On 4/13/05, Paul Querna <ch...@force-elite.com> wrote:
> Olaf van der Spek wrote:
> > Hi,
> >
> > I originally posted this feature request to the bug tracker, but Joe
> > Orton suggested it'd post it here instead, so here it is.
> >
> > I'd like to see a new 'MPM' that basically works like this:
> > A single or few-threaded, non-blocking frontend that accepts incoming
> > connections, receives requests and sends responses.
> > A multi-threaded or multi-processed backend that processes requests, generates
> > responses and passes the responses to the frontend for sending to the client.
> >
> > The advantage of this scheme would be that you can handle a (much) bigger
> > number of clients/persistent connections with less resources.
> >
> > The event MPM is a step in the right direction, but not 'good' enough.
> >
> > A scenario with multiple backends may be possible to, for example one
> > running as user A, one as user B, etc.
> > Or one multi-threaded backend for static content and one
> > multi-processed backend for dynamic content (PHP).
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=32243
> >
> 
> I agree with just about everything you said, at least in concept.
> 
> I am willing to help out, but I don't have the time or resources to head
> up this type of project right now.  If you do the initial work, I would
> love to help get such an MPM into the mainline tree.

Wouldn't it be possible to start this 'transition' by writing a module
that forwards the request to a separate backend process?
That way, you could safely run the threaded MPM and still use PHP in a safe way.

Re: Single-threaded/non-blocking frontend and multi-threaded/processed backend

[Olaf van der Spek <ol...@gmail.com>]

On 5/10/05, Phillip Susi <ps...@cfl.rr.com> wrote:
> Why have a separate 'frontend' and 'backend'?

Because for example PHP is not thread-safe and PHP may (easily) crash
(and you don't wish to allow that to crash the entire server).
Or because you wish to run one backend as user A and another backend as user B.

Re: Single-threaded/non-blocking frontend and multi-threaded/processed backend

[Phillip Susi <ps...@cfl.rr.com>]

Why have a separate 'frontend' and 'backend'?

One of these days when I get some spare time, I plan on rewriting 
mpm_winnt to use a small pool of threads which will use unbuffered zero 
copy overlapped IO and an IO completion port as the notification 
mechanism.  The pool of worker threads will wait on the IOCP for 
incoming data and as data comes in on any of the connected sockets, it 
wakes one thread to process the data.  The MPM would then pass the data 
on down the handler/filter chain, and it is currently my understanding 
that most of the time, the filters in the chain don't make other 
blocking system calls, but rather end up calling back into the apr/mpm 
to get more data, at which point the mpm would be free to handle IO on 
other sockets.

This system would allow fast and efficient IO on the level of 
TransmitFile(), only not restricted to sending unmodified on disk files. 
  I once wrote a simple FTP server using this mechanism and it was able 
to stream a large file over a fast ethernet network at 11,820 KB/s using 
virtually zero cpu time.  I believe that the apache2 bucket brigade 
design is nearly ideal for this system as the various filters and 
handlers can produce and/or modify data as they see fit, and it will 
still be sent and received over the network without the need for the 
user/kernel buffer copies.  It would also allow a small pool of worker 
threads to serve tens or even hundreds of thousands of clients.  I 
believe that BSD has a similar system called kqueue and posix aio.  To 
my knowledge, Linux has no equivalent.

Olaf van der Spek wrote:
> On 4/13/05, Paul Querna <ch...@force-elite.com> wrote:
> 
>>Olaf van der Spek wrote:
>>
>>>Hi,
>>>
>>>I originally posted this feature request to the bug tracker, but Joe
>>>Orton suggested it'd post it here instead, so here it is.
>>>
>>>I'd like to see a new 'MPM' that basically works like this:
>>>A single or few-threaded, non-blocking frontend that accepts incoming
>>>connections, receives requests and sends responses.
>>>A multi-threaded or multi-processed backend that processes requests, generates
>>>responses and passes the responses to the frontend for sending to the client.
>>>
>>>The advantage of this scheme would be that you can handle a (much) bigger
>>>number of clients/persistent connections with less resources.
>>>
>>>The event MPM is a step in the right direction, but not 'good' enough.
>>>
>>>A scenario with multiple backends may be possible to, for example one
>>>running as user A, one as user B, etc.
>>>Or one multi-threaded backend for static content and one
>>>multi-processed backend for dynamic content (PHP).
>>>
>>>http://issues.apache.org/bugzilla/show_bug.cgi?id=32243
>>>
>>
>>I agree with just about everything you said, at least in concept.
>>
>>I am willing to help out, but I don't have the time or resources to head
>>up this type of project right now.  If you do the initial work, I would
>>love to help get such an MPM into the mainline tree.
> 
> 
> Wouldn't it be possible to start this 'transition' by writing a module
> that forwards the request to a separate backend process?
> That way, you could safely run the threaded MPM and still use PHP in a safe way.
>