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 <[EMAIL PROTECTED]> 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.
