On Jun 6, 2010, at 2:53 PM, Stefan Fritsch wrote: > On Sunday 06 June 2010, Brian Pane wrote: >> On Sun, Jun 6, 2010 at 5:03 AM, Graham Leggett <minf...@sharp.fm> >> wrote: [...] >> >>> We've also been playing with Varnish, one of the cooler things it >>> does is have the ability to suck up an entire response into a >>> RAM buffer and releasing the backend before playing out the >>> response to the browser. I've looked, and we can do this pretty >>> trivially in httpd as a simple connection filter. >>> >>> Very useful for expensive backends like php, instead of waiting >>> many hundreds or thousands of milliseconds for the client to >>> eventually close the connection before cleaning up the request >>> pool and release php resources, you dump the response into a >>> connection buffer, and destroy the request pool asap. >> >> That also would work well with the event MPM; in addition to >> freeing up the request pool, you'd be able to free up the request >> thread. >> >> As long as the documentation explained to users that they need to >> have enough memory to accommodate MaxClient * >> MaxOutputBufferedPerRequest (where the latter is a hypothetical >> name for a configurable limit on the amount of buffered output), >> such a feature would be a net win for lots of sites. > > There is already mod_buffer in trunk. From reading the docs, it should > be suitable for this purpose. Or is it missing some functionality? > > As an added feature, one could imagine dumping very large responses > into a tempfile.
and then sendfile() it out. The intent is that once httpd's job is "done", release everything it can and let the OS do what it's best at (rather than trying to replicate that within httpd, imo)
