httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: Single listener - multi-worker
Date Sun, 29 Jul 2001 14:31:52 GMT
On Saturday 28 July 2001 11:55, Greg Ames wrote:
> 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

See Justin's response, and my response to that.  Your proposal won't fix all
the problems.

> > 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.

a)  I have a real problem saying that this isn't a priority because it doesn't affect
production environments.  This affects MY production environment.  I have a small
web server that gets probably five or ten requests a month.  If I try to restart my server,
there is a very real chance that it won't succeed at a graceful restart.  This
problem isn't production/non-production sites, it is heavy/lightly hit sites.

> > 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.

No, we're not.  I'm saying that you are wrong to assume that the current
model is faster than the new one.  Nobody ever did any performance analysis
of either of them.  Since we are removing mutex contention on heavily hit sites,
I am very willing to believe that this model may be faster.  Add to that the ease
of maintaining the code, because it looks and acts more like the prefork model.

> > > 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.

Again, I don't see how.

> 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.

We have two candidates that are single process only, and mine, which is multi-process,
and is proven technology, since it was the only MPM for the first 6 months
of development.  Whatever, I am not arguing this point.  I will commit a new MPM that 
removes the problems people have been having.  People can then begin to work on 
the new code.  At some point, the current threaded MPM should be removed though, 
because it isn't safe in a production environment.

I should point out that the reason we started with the single-acceptor/multi-listener, was
because IBM used this model in it's Lotus Domino Go Webserver, and in their performance
benchmarks, it was faster.  I'm not saying it will continue to be so, but that was what they
found.

Ryan

_____________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net
-----------------------------------------------------------------------------

Mime
View raw message