httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: pool performance in the worker mpm
Date Fri, 23 Nov 2001 15:10:58 GMT
On Thu, Nov 22, 2001 at 11:57:22PM -0800, Brian Pane wrote:
> The worker MPM currently creates and destroys a
> ptrans pool for each connection.  This is somewhat
> of a performance bottleneck due to the mutex locking
> in apr_pool_destroy().
> We could avoid this problem by creating a persistent
> pool per worker thread and doing apr_pool_clear() instead
> of apr_pool_destroy.  But I'm guessing that there's a
> reason why the code doesn't do that already.  Can
> anyone comment on the rationale for the current design?

Yes. It is difficult to move the per-thread pool between the
worker thread and the listener thread. As you may recall, I came
up with a couple different designs and settled on two: the
current, and the "time-space tradeoff" (essentially one
condition variable per worker, and the queue works in reverse).
The last patch I posted with a title similiar to "time-space
tradeoff" was able to achieve reusability of pools as well
as a decreased dependence on the mutexes in the worker queue.
I'm not sure if that patch will still apply, but I'd be
interested in cleaning it up again if we'd like to revisit
this design.

> If we created a persistent pool in each worker thread,
> we might also be able to eliminate the locking in
> new_block() by enhancing the pool code to use a
> thread-private free block list.  This would eliminate
> essentially all the mutex operations during request
> processing.

That may still be a possibility, but you'll recall that this
was one of the goals of SMS. It would be ideal to optionally
turn off the new_block mutex if we are confident the pool
is entirely threadsafe.


View raw message