httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rose, Billy" <wr...@loislaw.com>
Subject RE: [PATCH] convert worker MPM to leader/followers design
Date Thu, 11 Apr 2002 19:29:47 GMT
Would the solution in my last email do what you are looking for?

Billy Rose 
wrose@loislaw.com

> -----Original Message-----
> From: Jeff Trawick [mailto:trawick@attglobal.net]
> Sent: Thursday, April 11, 2002 2:20 PM
> To: dev@httpd.apache.org
> Subject: Re: [PATCH] convert worker MPM to leader/followers design
> 
> 
> "Bill Stoddard" <bill@wstoddard.com> writes:
> 
> > > Right, the problem is that the listener needs to avoid doing the
> > > accept if the queue is full.
> > >
> > > That part is easy: add a "block_if_queue_full()" method on the
> > > fd_queue class, and have the listener call it before doing an
> > > accept.
> > >
> > 
> > I am not an expert on the worker MPM but I don't think that 
> is an accurate statement of
> > the problem.  The accept thread uses ap_queue_push() to 
> enqueue a socket for the worker
> > threads. ap_queue_push() will block if the queue is full.
> > 
> > The problem is that the queue can be EMPTY even when all 
> the worker threads are busy
> > handling connections.  The way the code is today, the queue 
> can hold ap_threads_per_child
> > elements. Now consider 2 x ap_threads_per_child connections 
> comming into the server at
> > once.. The first 1 x ap_threads_per_child connections will 
> be accepted and handled by the
> > worker threads. The next ap_threads_per_child connections 
> will get queued and this is
> > precisely the problem...
> 
> That is the problem I thought was being dealt with originally...
> After seeing it stated differently a couple of times I 
> figured I was confused.
> 
> probably-stupid idea: 
> 
> Maybe a counter of blocked threads can be cheaply maintained 
> within the
> existing serialization.  The listener can use this to decide if it
> should call accept() or give up the CPU.
> 
> But this bites
> 
> 1) when there is just one child process (wasted syscall)
> 
> 2) because it would normally go faster if the listener could stay just
>    ahead of the workers so that workers can dequeue new work when they
>    finish with the old without having to wait on the listener to
>    enqueue something
> 
> -- 
> Jeff Trawick | trawick@attglobal.net
> Born in Roswell... married an alien...
> 

Mime
View raw message