httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <>
Subject RE: conserving file descriptors vs. ap_save_brigade()
Date Wed, 03 Jul 2002 22:26:10 GMT
How big a problem is this really?  Most of the time, the content-length
filter isn't supposed to actually buffer the brigade.  It should only be
doing the buffering if we are doing a keepalive request and we can't do

My own opinion is that if we are in that situation, we are potentially
best served by just turning off keepalives.


Ryan Bloom        
645 Howard St.    
San Francisco, CA 

> -----Original Message-----
> From: Brian Pane []
> Sent: Thursday, July 04, 2002 11:44 AM
> To:
> Subject: conserving file descriptors vs. ap_save_brigade()
> I'm working on a fix to keep file buckets from being mmaped when
> they're set aside.  (The motivation for this is to eliminate the
> bogus mmap+memcpy+munmap that happens when a client requests a
> file smaller than 8KB over a keep-alive connection.)
> The biggest problem I've found is that the scalability of the
> content-length filter depends on a side-effect of the current
> mmap-on-file-setaside semantics.
> Consider the case of an SSI file that includes 10 non-SSI html
> files of 500 bytes each.  As content streams through the output
> filters, the content-length filter sets aside each bucket until
> it sees EOS.  Currently, the setaside of each of the 10 file
> buckets turns the file bucket into an mmap bucket.  The good
> news is that this keeps us from running out of file descriptors
> if a threaded MPM is handling a hundred requests like this at
> once.  The bad news is that the mmap causes a performance
> degradation.
> The solutions I've thought of so far are:
> 1. Change the content-length filter to send its saved brigade
>    on to the next filter if it contains more than one file
>    bucket.  (This basically would match the semantics of
>    the core output filter, which starts writing to the socket
>    if it finds any files at all in the brigade.)
>       Pros: We can eliminate the mmap for file bucket setaside
>         and not have to worry about running out of file descriptors.
>       Cons: We lose the ability to compute the content length
>         in this example.  (I'm so accustomed to web servers not
>         being able to report a content-length on SSI requests
>         that this wouldn't bother me, though.)
> 2. Create two variants of ap_save_brigade(): one that does a
>    setaside of the buckets for use in core_output_filter(), and
>    another that does a read of the buckets (to force the mmap
>    of file buckets) for use in ap_content_length_filter().
>       Pros: Allows us to eliminate the mmap on small keepalive
>         requests, and doesn't limit our ability to report a
>         content-length on SSI requests.
>       Cons: We'll still have a performance problem for a lot of
>         SSI requests due to the mmap in the content-length filter.
> I like option 1 the best, unless anyone can think of a third option
> that would work better.
> --Brian

View raw message