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 goals: - 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. --Brian
