Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Thu, 04 Jul 2002 11:43:41 -0700
From: Brian Pane <bpane@pacbell.net>
Subject: conserving file descriptors vs. ap_save_brigade()
To: dev@httpd.apache.org
Message-id: <1025808222.1649.26.camel@localhost>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7BIT

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