httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: mod_include vs file descriptors
Date Sun, 11 Nov 2001 05:51:40 GMT
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				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message