httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Austin Gonyou <aus...@coremetrics.com>
Subject Re: worker MPM bugs (was Re: [PATCH] Possible fix for worker MPM perf ormance problem)
Date Thu, 25 Apr 2002 19:31:44 GMT
Is it possible, maybe already done, to *tag* the request in some way as
it is pushed into the stack(queue) and maintain some kind of hash or
other mechanism, based on time(age of request), to pull the oldest first
back out, perform service then discard? 

I suppose that's essentially a FIFO though, isn't it? Well, that
methodology, with possible parallel stacks, one per child, could result
in rather quick servicing of oldest new requests that were receieved
during child spawn time. 

Just curious.


On Thu, 2002-04-25 at 11:57, Aaron Bannert wrote:
> On Thu, Apr 25, 2002 at 11:30:54AM -0400, Bill Stoddard wrote:
> > Would someone care to see if this fixes the worker MPM performance
> problem reported
> > earlier on the list (request-per-second dropping when clients exceeded
> threadsperchild)?
> > This patch defers starting the listener untill -all- the workers have
> started.
> 
> I'm not really sure how this would fix the performance problems, and
> given
> the current theory it might even exacerbate it. The current hypothesis
> is that when we run out of available workers in all available children,
> and we are waiting for a new child to be spawned, connections continue
> to be accepted and placed in a queue*, and as such aren't able to be
> immediately serviced as soon as the new child is started.
> 
> A simple fix would be to prevent the queue* from accepting more
> connections until there is an idle worker thread available. The reason
> I have hesitated to make this change is because it would alter the
> places where the listener thread may enter blocking calls, and would
> probably break graceful/non-graceful restarts. If I get a little
> time I will try to look in to this again this weekend.
> 
> * When I say "queue" I really mean stack. In thinking about this problem
> over the last few days I realized that we should convert back to a true
> LIFO, otherwise it is possible for a request to sit at the back of the
> stack for a long time before it is serviced.
> 
> 
> Summary of worker bugs that need to be fixed:
> 
> - convert fd_queue back into a LIFO
> - add a counter that blocks ap_queue_pop() until there are available
> workers
>   (without breaking restarts/shutdown).
> - add a way to track open socket descriptors; when we get the signal to
>   do a hard shutdown of the server, walk down this set and close the fds
>   so we can halt any long-running requests.
> 
> -aaron
-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: austin@coremetrics.com

"It is the part of a good shepherd to shear his flock, not to skin it."
Latin Proverb

Mime
View raw message