httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: directory_walk performance
Date Mon, 25 Jun 2001 01:52:46 GMT
that works :)

however you can't quite handle /home/*/public_html that way can you?
ap_core_reorder_directories allows for those simple, single
path-component, wildcards.

-dean

On Sun, 24 Jun 2001, Brian Pane wrote:

> Thanks for the pointer; I'll see if I can apply the 'pre-merging'
> concept on top of Will's version of directory_walk.  In the meantime,
> I think I've figured out how to generalize the idea to cover pre-merging
> of all non-regular-expression-based directories.  Thanks to the
> sorting done by ap_core_reorder_directories, and directory_walk's
> corresponding pattern of handling all the non-regex directory matches
> before any of the regex ones, it's possible to precompute the merged
> config vectors for all the non-regex directories as a final post-config
> step before handling any requests.  E.g., if a server has <Directory>
> blocks for '/' and '/foo' and '/foo/bar', it's guaranteed that any request
> matching '/foo/bar' will have matched '/' and '/foo' also, so we can
> 'pre-inherit' the configs for '/' and '/foo' into the config vector for
> '/foo/bar' at startup rather than doing the merge repeatedly on each
> request.  I prototyped this algorithm for the current directory_walk,
> and it seems to work properly, but I haven't done extensive testing.
>
> --Brian
>
>
> rbb@covalent.net wrote:
>
> >Just a heads up, because I know he's off-list this weekend.  Will Rowe has
> >been looking at some of this stuff recently.  He has basically re-worked
> >directory walk to take advantage of a lot of the stat() calls that have
> >already been made.  Brian, I would suggest sending him e-mail on Monday so
> >that you can take advantage of his work.  He says it's not quite ready for
> >public consumption yet, but I'm sure he'll send it if there is interest.
> >BTW, this idea is great, I would love to see a patch, especially if it can
> >be generalized at all!
> >
> >Ryan
> >
> >On Sat, 23 Jun 2001, dean gaudet wrote:
> >
> >>that sounds good.
> >>
> >>it's just like constant-folding :)
> >>
> >>can you generalise it any?  Alias and mod_userdir can add more constant
> >>factors in the path.
> >>
> >>-dean
> >>
> >>On Fri, 22 Jun 2001, Brian Pane wrote:
> >>
> >>>More fun with gprof...
> >>>directory_walk is one of the bigger consumers of user-mode CPU time in
> >>>the current 2.0 httpd source, due largely to its calls to
> >>>ap_merge_per_dir_configs.
> >>>
> >>>For a typical configuration that has one <Directory> config for '/'
and
> >>>another for
> >>>the document root path, it looks like all requests for real files will
> >>>follow the
> >>>same pattern:
> >>>  * Initialize per_dir_defaults to be the default_lookups for the vhost
> >>>matching
> >>>     the request
> >>>  * Merge the configs for '/'
> >>>  * Merge the configs for the document root path
> >>>
> >>>I.e., the same merge of the / and /document/root configs is happening on
> >>>every
> >>>request.
> >>>
> >>>Assuming that this configuration style (with a <Directory> block for
the
> >>>document root path) is indeed common, would it be feasible to precompute
> >>>the merge of the '/' configs with the /document/root configs after
> >>>initialization
> >>>to support optimized handling of this case in directory_walk?  In the
> >>>implementation
> >>>I'm thinking of, the logic in directory_walk would look something like:
> >>>    if (path begins with sconf->ap_document_root) {
> >>>          per_dir_defaults = precomputed merged configs for document root;
> >>>          scan the rest of the path (after the docroot prefix) for
> >>>possible additional dir matches;
> >>>    }
> >>>    else {
> >>>        use the current algorithm;
> >>>    }
> >>>
> >>>Would that sort of optimization make sense, or is it too special-purpose
> >>>(or too
> >>>incorrect, even) to be generally useful?
> >>>
> >>>Thanks,
> >>>--Brian
> >>>
> >>>
> >>>
> >>
> >
> >
> >_______________________________________________________________________________
> >Ryan Bloom                        	rbb@apache.org
> >406 29th St.
> >San Francisco, CA 94131
> >-------------------------------------------------------------------------------
> >
> >
>
>
>
>


Mime
View raw message