httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: Single listener - multi-worker
Date Sat, 28 Jul 2001 17:13:16 GMT
On Friday 27 July 2001 18:53, Greg Ames wrote:
> Ryan Bloom wrote:
> > Unless somebody objects, I will commit my latest patch to the threaded
> > MPM later this weekend. This is the patch that implements a multi-process
> > single acceptor/multi-worker model.
> There's another thing that bothers me a little about this (nothing to do
> with the scoreboard).
> Do we really know that this model, and in particular this code, is a
> winner in terms of performance on some platform we care about?  It could
> well be, but I don't recall seeing a benchmark.  A benchmark would be
> really nice before we rip the old code out.  If it doesn't perform
> better, why would we do it?

This has NOTHING to do with performance.  It has to do with fixing the bugs in the
current threaded model.  It is not possible to fix the restart/shutdown bugs in the
current threaded model, 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.

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.

> Just to be difficult, let's say some platforms do better with the new
> code, and others do better with the existing code.  Then what?

Unless you can fix ALL the bugs in the current MPM, this is a moot point.

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


Ryan Bloom               
Covalent Technologies

View raw message