More worker ideas Re: cvs commit: httpd-2.0/server/mpm/worker worker.c fdqueue.c fdqueue.h

[Brian Pane <bp...@pacbell.net>]

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

Re: More worker ideas Re: cvs commit: httpd-2.0/server/mpm/worker worker.c fdqueue.c fdqueue.h

[Aaron Bannert <aa...@clove.org>]

On Sat, Apr 27, 2002 at 07:39:24PM -0700, Brian Pane wrote:
> 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.

Yes! The other neat thing about this is we get to balance the
critical path between two mutex regions, rather than one_big_mutex.

> 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.

++1 on both accounts. I was also thinking that we could make the queue
elements simple pointers, rather than 2 elements in a structure. That
way the element lookups can happen outside of the mutex region, and
inside we can have a simple struct* assignment.

-aaron