How does MPM actually work?

[Scott MacVicar <sc...@spamcop.net>]

Hi,

I've been trying to get my head around the MPM module and I realise its 
a hybrid of multi-threading and multi-processing. Can someone either 
confirm what I'm saying or correct any obvious mistakes.

1 Main httpd process
X server processes
Y child threads

the main httpd process handles the socket connections which passes it to 
one of the server processes and once its been processed there any data 
to be sent back to the client is handled by one of the child threads?

If so how do you pass data between the different processes, pipes or 
shared memory?

I read about the various directives for the mpm module and had a look 
through the code but I'm just trying to get a better understanding. If 
there is a document somewhere that I've missed that explains this then 
apologies.

Cheers,
Scott

Re: How does MPM actually work?

[Jeff Trawick <tr...@gmail.com>]

On Fri, 03 Dec 2004 18:07:12 -0500, Ronald Park <ro...@cnet.com> wrote:
> And, given the problem described about long running request causing
> children to potentially fall off the scoreboard, what happens in the
> following scenario:
> 
> Each of the X servers has 1 or more threads working on loooong requests.
> 
> Other threads in each of those servers finish off M requests, meeting
> (or exceeding?) MaxRequestsPerChild.  (BTW, could you explain which
> thread takes on responsibility for nicely shuting down the process?
> The thread which pushed us past MaxRequestPerChild, the long running
> thread (when it eventually finishes) or some 'master' thread?)

see server/mpm/worker/worker.c; a call to signal_threads() gets
everybody to exit; that can be called in various conditions on
different threads

> Under these circumstances, the X children can't (yet) exit... but
> there's still more requests coming in.  And what happens when the
> listen queue fills up in the parent?

There is no listen queue in the parent.  Incoming connections are
queued only in the kernel before a thread in a child process calls
accept().

In this [basket] case, you have MaxClients child processes, each with
one thread processing an active request; there are no listener threads
since the processes are in the act of exiting and the listener thread
exits in that case, so everything queues up in the kernel until the
kernel accept queue overflows.

This is similar in effect to What happens in the more normal
MaxCLients conditions: Listener threads won't exit, but they will
refuse to accept more connections if there is no thread available to
process the connection, so everything queues up in the kernel until
the kernel accept queue overflows.

This, like other MaxClients conditions, ends when a request ends.

Re: How does MPM actually work?

[Ronald Park <ro...@cnet.com>]

And, given the problem described about long running request causing
children to potentially fall off the scoreboard, what happens in the
following scenario:

Each of the X servers has 1 or more threads working on loooong requests.

Other threads in each of those servers finish off M requests, meeting
(or exceeding?) MaxRequestsPerChild.  (BTW, could you explain which
thread takes on responsibility for nicely shuting down the process?
The thread which pushed us past MaxRequestPerChild, the long running
thread (when it eventually finishes) or some 'master' thread?)

Under these circumstances, the X children can't (yet) exit... but
there's still more requests coming in.  And what happens when the
listen queue fills up in the parent?

Thanks,
Ron

On Thu, 2004-12-02 at 11:46 -0500, Jeff Trawick wrote:
> On Thu, 02 Dec 2004 13:01:49 +0000, Scott MacVicar <sc...@spamcop.net> wrote:
> > Hi,
> > 
> > I've been trying to get my head around the MPM module and I realise its
> > a hybrid of multi-threading and multi-processing. Can someone either
> > confirm what I'm saying or correct any obvious mistakes.
> > 
> > 1 Main httpd process
> 
> call this the parent process
> 
> > X server processes
> 
> call this the child processes
> 
> > Y child threads
> > 
> > the main httpd process handles the socket connections which passes it to
> > one of the server processes and once its been processed there any data
> > to be sent back to the client is handled by one of the child threads?
> 
> parent process does not handle connections; it sets up the listening
> sockets at initialization, but only child processes will accept new
> connections
> 
> > If so how do you pass data between the different processes, pipes or
> > shared memory?
> 
> not done
> 
> (caveat: perchild is a special beast that sends file descriptors over
> unix sockets from one child process to another; it is just an
> experiment and its behavior shouldn't confuse the issue)
> 
> > I read about the various directives for the mpm module and had a look
> > through the code but I'm just trying to get a better understanding. If
> > there is a document somewhere that I've missed that explains this then
> > apologies.
> 
> take worker MPM, for example
> 
> each child process has a thread that listens for new connections; when
> it gets one, it uses apr_thread_cond*() APIs to dispatch a worker
> thread to handle that connection
-- 
Ronald Park <ro...@cnet.com>

Re: How does MPM actually work?

[Jeff Trawick <tr...@gmail.com>]

On Thu, 02 Dec 2004 13:01:49 +0000, Scott MacVicar <sc...@spamcop.net> wrote:
> Hi,
> 
> I've been trying to get my head around the MPM module and I realise its
> a hybrid of multi-threading and multi-processing. Can someone either
> confirm what I'm saying or correct any obvious mistakes.
> 
> 1 Main httpd process

call this the parent process

> X server processes

call this the child processes

> Y child threads
> 
> the main httpd process handles the socket connections which passes it to
> one of the server processes and once its been processed there any data
> to be sent back to the client is handled by one of the child threads?

parent process does not handle connections; it sets up the listening
sockets at initialization, but only child processes will accept new
connections

> If so how do you pass data between the different processes, pipes or
> shared memory?

not done

(caveat: perchild is a special beast that sends file descriptors over
unix sockets from one child process to another; it is just an
experiment and its behavior shouldn't confuse the issue)

> I read about the various directives for the mpm module and had a look
> through the code but I'm just trying to get a better understanding. If
> there is a document somewhere that I've missed that explains this then
> apologies.

take worker MPM, for example

each child process has a thread that listens for new connections; when
it gets one, it uses apr_thread_cond*() APIs to dispatch a worker
thread to handle that connection