httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: are we ready to roll?
Date Fri, 10 Aug 2001 15:12:16 GMT
Ryan Bloom wrote:
> On Thursday 09 August 2001 22:17, Greg Ames wrote:
> > > Known issues with 2.0.23:
> > >
> > > 1) Win9x, WinME, and Netware do not yet work.
> > > 2) Unix: The threaded MPM might take longer than expected to perform
> > >    a graceful restart if an insufficient number of incoming requests
> > >    are being received at the time of the restart.
> >
> > Sorry I missed it when you first wrote this, but the sentence above
> > isn't stricly true, and I believe it may be causing some folks to be
> > overly alarmed about threaded.
> >
> > Graceful restarts happen just as quickly in threaded as with prefork, as
> > far as parsing the config file, serving new http requests with the new
> > config, and finishing old requests are concerned.  The one and only
> > thing that may take longer under low load conditions is cleaning up idle
> > threads and their processes from the old generation.  I don't consider
> > that much of a concern, especially since any new requests help resolve
> > the situation.
> Greg, I'm sorry, but this is just not true.  Please take a look at the code.  

I'm quite familiar with it, as you are well aware.

>                                                                   The
> way that graceful restarts work in the threaded mode, is that we accept the
> connection, 

bzzzzt!   wrong.  Now we're getting somewhere - I think I understand why
you think threaded has a problem.

The way that graceful restarts work in threaded, is that one thread is
blocked in apr_poll.  When the parent initiates graceful restart, it
writes at least one character per child process to the PoD.  This wakes
up the thread blocked in poll, who sets workers_may_exit, releases the
mutex, sets ps->quiescing and exits.

If the next thread to get the mutex happens to be in the same process,
it doesn't do much beside release the mutex once more, decrement the
thread count and exit.  If the current mutex holder is in a different
process, then it goes into the poll etc as described in the paragraph

If the mutex holder happens to get awakened by a new connection before
the PoD is readable, it will server the request using the old
generation's config, just like in prefork.  

> serve the request, and then shutdown the thread.  Since threads
> serve a request before they are shutdown, having them sitting around means that
> the graceful restart hasn't been finished yet.  It also means that a site could be
> serving pages with the old config long after the graceful restart was signalled.

A site with threaded won't be serving pages with the old config any
longer than it will with prefork.

> Try doing graceful restarts on a server that isn't being hit continuosly.  

not a problem.

>  If you
> think this case doesn't matter, consider slashdot, and what will happen if you
> are running a server that is usually very quiet, but you believe that you will be
> being hit very hard soon.  Most people would re-config their server, and do a
> graceful restart to handle the load they fear.  With the threaded MPM, the first
> set of requests will be served with the old config instead of the new one.

no sir, it won't.  Any new requests receive after the PoD is seen are
served in new generation processes, just like in prefork

> I have been on site at a user who wanted to re-config their server everyday at
> 3:00pm, because they always got a big spike from 3:00 - 5:00, as people got
> ready to leave the office at the end of the day.  At other times, they didn't have the
> same load, so they wanted the server to use less resources.  With today's threaded
> MPM, I couldn't say to them that their server would only finish the current requests
> with the old config, and all new requests would be served with the new config.

If you see any evidence of new requests being served with the old
config, please let us know ASAP.  AFAIK, it just doesn't happen.


View raw message