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