httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: [PROPOSAL] spmt MPM
Date Thu, 19 Jul 2001 15:58:31 GMT
On Thu, Jul 19, 2001 at 06:44:41AM -0700, wrote:
> On Wed, 18 Jul 2001, Justin Erenkrantz wrote:
> > Hey, it serves pages on my Linux 2.4/glibc-2.2 box.  This is a
> > proof-of-concept.  Would any committer (remember, I'm not a committer
> > to httpd-2.0) be interested in committing a working and clean spmt
> > MPM if I submitted one?
> How does this MPM scale?  Meaning do I always have to have MaxClients
> threads in my process?  How does this handle graceful restart  (either it
> becomes mpmt, or it stops serving pages if one thread is handling a
> long-lived request)?

I am imagining that it is primarily used for debugging/analysis of our
code and its parallel characteristics within one process.  What locks 
are held that are affecting performance (in httpd, APR, libc, kernel)?
You could call it the "threaded-debug" MPM if you'd like.  That'd
scare most end-users off.  I don't care what the name is.  =)

With a tool such as flood (see httpd-test), we now have the ability to 
intelligently hammer a site and watch its performance.  By analyzing 
what is going on at the server (via pstack, etc.), we can obtain an 
idea of what we need to improve.  

In the past, I think part of the answer to performance problems in 
a threaded httpd has been to add more processes rather than 
addressing the core parallel contention issues inside of a process.  
This merely hides the problem of having serious lock contentions even 
within a mpmt MPM.  (I see mpmt as merely an extension of spmt.)

I believe that having a spmt MPM available makes it easier to ask 
these questions.  And, given the current state of the mpmt MPM, I think
it would be worthwhile to step back and make sure a single process in
the mpmt MPM would work well.

As far as maintaining the spmt MPM, as I said, I volunteer to maintain
it for now.  That's the best I can offer.  -- justin

View raw message