httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: content-length filter and r->bytes_sent
Date Sun, 14 Jul 2002 18:22:21 GMT
On Sun, 2002-07-14 at 09:35, Cliff Woolley wrote:
> On Sun, 14 Jul 2002, Brian Pane wrote:
> >     For example, given a .shtml file that includes several small,
> >     non-parsed files, the setaside logic in the C-L filter will do
> >     an mmap+memcpy+munmap of each of the included files.
> All that needs to happen here is that file_bucket_setaside() needs to be
> updated to use the new apr_file_setaside() API.

That alone wouldn't fix it.  In fact, I noticed the C-L filter
problem when I first tried to use apr_file_setaside() within
the file_bucket_setaside().

Setting aside a lot of file descriptors just isn't scalable.
If you have, say, 100 threads per httpd child process, and the
OS has a default limit of 1024 file descriptors per process,
you can run out of descriptors too easily if you're serving
a lot of mod_include requests with half a dozen small include
files per request.  Alternately, an attacker who figures out
which pages have a lot of include files can create a DoS by
sending parallel requests for the pages that cause the most
file descriptors to be set aside.

I don't see any way to support the widespread use of file bucket
setaside in a high-performance server.  If we implement it with
mmap+memcpy+munmap, there's a performance degradation (we're
moving far away from the goal of zero-copy), plus a scalability
degradation on some multiprocessor systems where mmap or munmap
doesn't scale well.  But if we implement it by setting aside the
file descriptor instead, then we risk running out of descriptors
unless we're careful about managing an upper bound on the number
of set-aside files.

Yes, we should change the file bucket setaside to use
apr_file_setaside().  And the core output filter will need
a bit of tuning to manage the tradeoff between three conflicting
  - Do a small number of large network writes for higher throughput
  - Don't run out of file descriptors
  - Guarantee zero-copy for files
I'm confident that we can make this work in the core output
filter--it may involve, for example, having a tunable limit
on the number of file descriptors per requests that it's
allowed to buffer before doing a socket write.  But that will
only work if we can guarantee that no filter above it is doing
its own file descriptor setaside.  Thus all my proposed changes
for the C-L filter are focused on moving data through it without
buffering delays, so that we can implement a more scalable
setaside solution in the core output filter.


View raw message