httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
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
chunking.

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

Ryan

----------------------------------------------
Ryan Bloom                  rbb@covalent.net
645 Howard St.              rbb@apache.org
San Francisco, CA 

> -----Original Message-----
> From: Brian Pane [mailto:bpane@pacbell.net]
> Sent: Thursday, July 04, 2002 11:44 AM
> To: dev@httpd.apache.org
> 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
> 



Mime
View raw message