On 10/15/08 6:56 PM, "Graham Leggett" <[EMAIL PROTECTED]> wrote:
> Obviously, if the loop comes round more than once, then the client comes
> into play. This definitely needs to be fixed, it is a big performance issue.
Could a more general purpose optimization be done? I was thinking of a
generic "store and forward" filter. Basically, just dump the entire brigade
into some storage (memory, file) in a loop (like deflate sorta does) without
sending to client at all until the response is finished. This would work
for proxy, php, some strange handler, etc.
A small test I did was a module had a filter that just dumped all the
brigade contents into a temp file. When it saw EOS, it would then send the
complete file to the client (via sendfile, mmap, etc..) and remove the
tempfile. Almost like an in process "X-Sendfile." This very rudimentary
module increased overall throughput of some large SSI files by about 20% and
completely shielded origin servers from clients in some proxy tests. It
also did not consume very much memory (although I was writing the temp files
into /dev/shm on Linux).
Basic logic - I ignored flush and meta buckets in my tests:
while (!APR_BRIGADE_EMPTY(bb)) {
e = APR_BRIGADE_FIRST(bb);
if (APR_BUCKET_IS_EOS(e)) {
create a file bucket with the tempfile and send it along
tempfile was opened with APR_DELONCLOSE
} else {
apr_bucket_read(e,
write content to temp file
}
apr_bucket_delete(e);
}
apr_brigade_cleanup(bb);
return APR_SUCCESS;
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
