httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: 2.0 Scoreboard (was Re: Management of thread pools)
Date Sat, 19 Jun 1999 00:28:58 GMT

On Fri, 18 Jun 1999, Manoj Kasichainula wrote:

> We've talked about tearing a lot of the stuff out of the current
> scoreboard and putting it into some sort of query function. If we do
> this, the best things to put in the scoreboard are stats needed to
> manage the server pool, because we don't want to require the parent to
> query every child every second (right?)

Did you take a look at http_event.c in the select/pthread hybrid I posted? 
I showed a method whereby which one process can maintain a pool of threads
large enough to service the current demand without a scoreboard... all it
takes is a simple counter that goes along with the request queue.

A similar trick can be done for processes... every second the parent wakes
up and does a non-blocking select() on the listening fd, if it's marked
ready for listen, then all the children are busy, so spawn another child. 
How do you shrink the number of children?  Dunno, don't have a trick for
that yet. 

The 1.x scoreboard is a multicpu nightmare -- it causes cache lines to be
whacked around from CPU to CPU... it just doesn't scale well. 

> Another option would be a less major tweak. The scoreboard would keep
> per-thread stats instead of per-request stats. Then, each thread can
> interact with the scoreboard as it does now, with no synchronization.
> The scoreboard wouldn't be humongous in the async request handler
> model Dean's doing, but it wouldn't be small either.

The scoreboard shows requests in progress, well, actually, connections in
progress (gotta stop confusing the two).  The proper index is (pid_t,
conn_rec *) ... threads don't enter into the picture really. 

I would be totally happy if getting the "scoreboard contents", the stats
in essence, was something similarly expensive as running "ps".  It's
really the same operation.  And the MPM has to be involved -- because it
has to communicate with any other processes around.

This may even be as complex having a global conn_rec * list, a mutex for
it, and a pipe to each process through which any process can slurp up the
data to display for mod_status.  I don't mind complexity that's invoked
only on every hit to mod_status... I do mind multi-cpu shared data that's
tweaked all the time...

It's important to separate the two uses of the scoreboard.  I mean,
currently we count the child states to figure out #idle, and such.  If we
had atomic increment and decrement we wouldn't need to count... and for
the purpose of maintaining the pool of processes/threads/whatever all you
need is #idle, no other stat.  Everything else the scoreboard does is for
human consumption (and slows things down :)


View raw message