httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject More worker ideas Re: cvs commit: httpd-2.0/server/mpm/worker worker.c fdqueue.c fdqueue.h
Date Sun, 28 Apr 2002 02:39:24 GMT
aaron@apache.org wrote:

>aaron       02/04/27 18:45:00
>
>  Modified:    server/mpm/worker worker.c fdqueue.c fdqueue.h
>  Log:
>  Add a "queue_info" structure to the worker MPM. This is used to prevent
>  the listener thread from accept()ing more connections than there are
>  available workers. This prevents long-running requests from starving
>  connections that have been accepted but not yet processed.
>  
>  The queue_info is a simple counter, mutex, and condition variable. Only
>

I was going to complain about the addition of yet another mutex
to the critical path of request processing, but it got me thinking
about an approach to making worker faster: shorten the time spent
in the mutex-protected region.

By shortening the code path between the lock and the unlock, we
can reduce the probability that two or more threads will be
contending for the mutex at once.  And uncontended mutexes have
a lot less overhead.

I'm going to experiment with streamlining the code within the
mutex-protected blocks of the fdqueue functions to see how much
it helps the multiprocessor performance.  At first glance, the
candidates for optimization are:
   * In the case where we can't recycle a pool in ap_queue_pop(),
     move the destruction of the pool *outside* the mutex-protected
     block.
   * Maybe change the queue size to a power of two so that we can
     replace the modulo operations with a bit mask.

--Brian




Mime
View raw message