httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Akins, Brian" <Brian.Ak...@turner.com>
Subject Re: strange usage pattern for child processes
Date Thu, 16 Oct 2008 13:15:32 GMT
On 10/15/08 6:56 PM, "Graham Leggett" <minfrin@sharp.fm> 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


Mime
View raw message