Date: Sat, 19 Jun 1999 02:08:21 -0700 (PDT)
From: Dean Gaudet <dgaudet@arctic.org>
To: Apache Developers <new-httpd@apache.org>
Subject: Re: 2.0 Scoreboard (was Re: Management of thread pools)
In-Reply-To: <19990618231930.A13246@io.com>
Message-ID: <Pine.LNX.3.96dg4.990619020314.27639k-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


On Fri, 18 Jun 1999, Manoj Kasichainula wrote:

> On Fri, Jun 18, 1999 at 05:28:58PM -0700, Dean Gaudet wrote:
> > 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. 
> 
> Hmmmm. That's a cool idea. This only lets us set a spare thread limit
> of 1, though. Is that enough padding?

Just do exponential spawning... you still need a limiter though --
something to bring things back down...

ah that's easy actually, just timeout the select/accept loops in the
children, if they don't accept anything in N seconds then let them die
off.

Bet that'd do it.

> > 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. 
> 
> Don't most decent MP systems snoop the bus to pick up writes to RAM?

Well we don't align things on cache lines, so it's highly possible that a
scoreboard entry straddles a cache line and so two processors end up
fighting for it... even though it all works right, this isn't optimal
because it makes those mem accesses expensive. 

> Another way to eliminate the idle counting necessity of the scoreboard
> is to have a fixed number of processes, and to make each process run
> its own thread pool. Each child would just add and delete threads
> without changing the number of processesi or caring at all about what
> the other processes are up to. This might cause thrashing, though,
> with threads just dying in one process and starting in another.

I'm totally planning on having a fixed number of processes in the mpm I'm
working on... I don't think it makes sense to vary in two dimensions. 
I'll fix the number of processes and vary the number of threads.  The
thing I'm wondering about is how well the requests will balance across the
processes... that should be an interesting problem. 

Dean