httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: fix for hybrid server problems.
Date Tue, 04 May 1999 18:20:39 GMT
On Tue, 4 May 1999, Rodent of Unusual Size wrote:

> Dean Gaudet wrote:
> > 
> > On Tue, 4 May 1999, Manoj Kasichainula wrote:
> > 
> > >              Do we mind that there will be no way to get a mod_status
> > > display of our gracefully dying children after a graceful shutdown?
> > 
> > Didn't think about that... hmm.
> 
> Surely they'll still be displayable from other processes that
> have completed the restart?  Just not from any that are still
> in the throes.

I think there are two issues:

- a process won't exit (and free up its 64 scoreboard slots) until it is
  done serving all of its requests... 64 slots is a lot of memory

- we have no way to note the static fd/mmap responses that are being taken
  care of by the event thread

Shared memory is expensive on some systems -- it's non-swappable.  The
event thread will give us the possibility of handling thousands upon
thousands of long haul clients... which makes it really hard to statically
allocate enough memory to record all the requests. 

I'm thinking that a better solution would be to record only processes in
the shared memory scoreboard.  (There's probably a few stats we can record
on a per-process level.) 

Then within each process, we dynamically allocate scoreboard information
for each connection and store it in a linked list.  Plus we provide a
mechanism for processes to fetch this list from other processes. 

There's a few ways to do this... I haven't thought hard about it yet. 

Finally, we hide all of this under a simple API:  ap_open_scoreboard(),
ap_read_scoreboard(), ap_close_scoreboard()... which works somewhat like
opendir/readdir.  We need to hide it this way -- because the scoreboard
will be different on NT, for example, where multiple processes are
impossible (can't do accept() on same socket in multiple processes).

Dean


Mime
View raw message