Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Thu, 19 Jul 2001 08:58:31 -0700
From: Justin Erenkrantz <jerenkrantz@ebuilt.com>
To: new-httpd@apache.org
Subject: Re: [PROPOSAL] spmt MPM
Message-ID: <20010719085831.X324@ebuilt.com>
References: <20010718233945.T324@ebuilt.com>
 <Pine.LNX.4.30.0107190634490.1590-100000@koj.rkbloom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.30.0107190634490.1590-100000@koj.rkbloom.net>;
 from rbb@covalent.net on Thu, Jul 19, 2001 at 06:44:41AM -0700

On Thu, Jul 19, 2001 at 06:44:41AM -0700, rbb@covalent.net 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