httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: Single listener - multi-worker
Date Sat, 28 Jul 2001 18:55:50 GMT
Ryan Bloom wrote:
> 
 
> This has NOTHING to do with performance.  It has to do with fixing the bugs in the
> current threaded model.  

Good answer!  I think we're on the same wavelength, believe it or not
:-)

> It is not possible to fix the restart/shutdown bugs in the
> current threaded model, 

ummm, I disagree

> because of the way that pthreads handles mutexes, and
> how you have to wake threads up out of mutexes
> 
> This model has only one thread sitting in the accept_mutex, so we completely
> remove that problem.  If you have some other way to fix the accept_mutex being
> a non-cancelable state in the current threaded MPM, I would really like to hear it.

OK, here is another way to fix it:

This problem occurs when incoming connections dry up, mostly in
non-production environments (therefore it's not real high on my priority
list, but whatever).  If worker processes aren't exiting quickly enough,
before starting with the SIGTERMs, check the scoreboard to see how many
processes don't have the new generation number (restarts only), pid ==
0, quiescing, or a "G" somewhere in the worker_scores.  Send that many
dummy connects.  But don't bother with this if the dummy connect sender
ever times out, because we're probably overloading the kernel's
connection queue.

> As for the performance, this is where we started when Manoj and I first wrote the threaded
> server.  We shifted to the current model because Bill and Manoj thought it would be faster.
> There have never been any benchmarks to prove that, but it was a feeling.

cool! we're in sync again.
 
> > It almost feels like this should be a new MPM until we know that no
> > important platforms need the current threaded model.  Platforms with no
> > thundering herd problem, especially if the kernel has the semantics to
> > wait for data to arrive before unblocking the accept(), might do really
> > well with the current model.  (I almost said FreeBSD, but it's got this
> > little problem with threads at the moment...)
> 
> Yes, some platforms MIGHT perform better with the current model, but it is only useful
> on platforms that don't have thundering herd, and in cases where you don't use
> multiple sockets.  Because, if you end up sitting in a mutex around select/accept statements,
> you won't be able to gracefully shutdown the server.

au contraire.  I think we can shut down the server even in a lab/test
environment, with the current model.  

But I do think one of the single listen multi thread MPMs would be an
interesting addition to our current collection of MPMs.  We have 3
candidates, last time I checked.  Why not have an MPM benchmark shootout
(after we get the next beta out the door)?   It might be fun.  

Greg

Mime
View raw message