As an end-user of apache, I'd like to chime in: please, please, please leave
the N processes with M threads model available -- "the hypothetical buggy
3rd party modules should be fixed rather than hacked around" is fine in
theory, but in practice I'd rather have an Apache that can soldier on
regardless of the crappy modules it's forced to run. Tuxedo has used the N
x M model for a long time with good results for similar reasons.
My $0.02
Thanks,
-b
-----Original Message-----
From: dean gaudet [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 17, 2001 4:13 AM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] Problems with MPM threaded
On Sat, 14 Jul 2001 [EMAIL PROTECTED] wrote:
> Having multiple processes each with multiple threads provides for FAR
> more robustness than just a single process with multiple threads.
ya know, i'm not really convinced of the desirability of this explanation
anymore. maybe the hypothetical buggy 3rd party modules should be fixed
rather than hacked around. and they won't be fixed as long as apache
continues to hide the problem.
however i can provide two more justifications which are pretty weak:
- userland thread libraries need multiple processes in order to get disk
i/o parallelism (and multi-cpu parallelism)
- suppose you configure apache with exactly the number of children as
you have processors. and suppose that somehow magically the CPU
requirements of each process' threads is about even. then a good
(kernel) scheduler will likely migrate each process to its own CPU and
time slice just the threads within that process. this will tend to
decrease the overall memory system traffic (because L2 caches won't be
competing for the same process' memory), and increase the TLB hit rate.
it may even be possible to avoid interprocessor interrupts every
time the memory map is changed (to make sure that remote TLBs are
up to date).
that's a lot of conditionals to get right.
-dean
