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 [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -----Original Message----- > From: Brian Pane [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 04, 2002 11:44 AM > To: [EMAIL PROTECTED] > 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 >
