On Sat, 14 Jul 2001, Justin Erenkrantz wrote:
> On Sat, Jul 14, 2001 at 09:19:17AM -0700, [EMAIL PROTECTED] wrote:
> > No! The threaded MPM does NOT and was not intended to implement a
> > thread-only server. It was designed to implement a hybrid thread/process
> > server. Because we expect both threads and processes, the rest of this
> > message is based on a misconception. Having multiple processes each with
> > multiple threads provides for FAR more robustness than just a single
> > process with multiple threads. If you want that, then you want the
> > perchild MPM, so that the number of threads can grow and shrink correctly.
>
> What are we gaining by having multiple children processes? I certainly
> don't think the robustness gained by having multiple children processes
> is all that great. And, it serves to make the threaded MPM code almost
Apache allows 3rd-party modules, which makes it much more likely that the
server will seg fault. If you only have one process, then your server
won't be serving any requests during the time it takes to start a second
server. Add to that the time it takes for the parent process to notice
that the child has died (up to 1 second), and you have missed serving a
lot of requests.
Now, add scalability concerns. The threaded MPM creates a set number of
threads per child process. This means that at ALL times, you have to have
enough threads to handle the maximum number of concurrent connections.
That is bogus. I realize that threads are less expensive than processes,
but come on. Why should have my enough threads in my server to handle my
peak load at all times?
The Perchild MPM was designed to allow you to grow the number of threads
in a given process. So, you can bring the number of threads down to 10 or
20, and grow as needed.
> unmaintainble. Perchild looks a little closer, but I still think it is
> tainted by having multiple children processes. Oh, and it needs the
> POD fix as well.
Perchild can have as few children as you want. Set it up to run 1 child,
and it will just have one child.
> By having the possibility of having other children processes, you now
> need a mechanism to kill all threads in the same process efficiently.
> You'd need to kick them out of the accept mutex, but I'm not seeing
> how that's going to happen quickly. -- justin
You need to be able to kill all threads in a process efficiently
regardless. We will always need to be able to re-spawn processes that
die, and we will always have the concept of MaxRequestsPerChild. If a
process is going to die and be replaced, then we need to kill all the
threads in that process as quickly as possible. Only allowing one
process at a time doesn't remove that requirement.
Feel free to create an MPM that only allows one process at a time, that is
why the MPM mechanism exists, but Threaded and Perchild were both designed
to allow multiple child processes for a reason.
Ryan
_____________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
-----------------------------------------------------------------------------
