On Saturday 10 November 2001 09:09 pm, Brian Pane wrote:
> This bit of mod_include's includes_filter() is likely to be a problem
> for servers with a lot of connections from slow clients:
>
> if ((parent = ap_get_module_config(r->request_config,
> &include_module))) {
> /* Kludge --- for nested includes, we want to keep the subprocess
> * environment of the base document (for compatibility); that means
> * torquing our own last_modified date as well so that the
> * LAST_MODIFIED variable gets reset to the proper value if the
> * nested document resets <!--#config timefmt-->.
> * We also insist that the memory for this subrequest not be
> * destroyed, that's dealt with in handle_include().
> */
> r->subprocess_env = r->main->subprocess_env;
> apr_pool_join(r->main->pool, r->pool);
> r->finfo.mtime = r->main->finfo.mtime;
> }
>
> The problem is that, by joing the pool with that of the parent request,
> the file descriptor for this .shtml file doesn't get closed until the
> parent pool goes out of scope. With a .shtml file that includes 9 other
> .shtml files, we'll have a total of 10 file descriptors open (11 including
> the socket to the client) until we finish sending the content to the
> client. That could seriously limit the number of clients that each child
> process can handle in the threaded or worker MPM.
>
> The easy solutions I can think of are:
> * Close the descriptor for each file immediately after mmap'ing it, or
> * Don't join the pools in includes_filter().
>
> Can anyone comment on the viability of these fixes, or any other suitable
> solution?
apr_pool_join is a no-op unless APR_POOL_DEBUG is enabled. If it isn't
enabled, which it shouldn't be on production servers, there will be no
performance penalty for that function.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
