httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: [PATCH] Update to Brian's patch to allocate brigades out of the bucket allocator
Date Sat, 21 Dec 2002 18:00:42 GMT
On Sat, 2002-12-21 at 02:05, Justin Erenkrantz wrote:

> Saying a response pool 'doubles' the memory is an absolute 
> non-starter.  Back that up, please.  If you're meaning the additional 
> 8kb minimum for the separate pool, I seriously can't believe that's 
> going to be a major concern.

I do consider it a cause for concern as we try to scale
the httpd to handle thousands of connections.

> A response pool solves the same problem as allocating the brigade 
> from a non-cleanup protected memory allocator, and I believe has 
> better long-term advantages for the overall architecture of httpd. 

I have mixed opinions on response pools.  They have all the usual
benefits of pools, but with a couple of big complications.  They're
great if they enable you to free up the request pool when you're
finished generating the response.  But there's data in the request
pool that really needs to survive until after the response has been
sent--specifically, anything needed in support of the logger.  That
leaves us with the choice of either keeping the request pool around
(which somewhat defeats the point of using a response pool) or
copying the needed request and connection info to the response pool
(which works but is slightly wasteful).  The other problem with
response pools is that they're pools.  If you have an app that's
generating a large response in small units, you'll have a lot of
small brigades being allocated from the response pool, and you
won't be able to free up any of that space until the entire
response is finished.  This is bearable for most HTTP connections,
but it won't work for connections that live forever.


View raw message