httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: directory_walk performance
Date Wed, 01 Aug 2001 17:48:32 GMT

  see my commit to core/request.c ... I've dropped in the new directory_walk

  I'd like us to optimize it for things we _know_ (e.g., it's given as a
<Directory > so skip the stat, unless FollowSymLinks isn't set, and assume
for the remainder of the request that it _is_ a directory) and then introduce
your optimizations.  Hopefully both branches in the same source help us keep 
running while we keep developing.  Focus on the second directory_walk function
since the first will be deprecated and removed when we've got it right :)


----- Original Message ----- 
From: "Brian Pane" <>
To: "new-httpd" <>
Sent: Friday, June 22, 2001 4:03 PM
Subject: directory_walk performance

> 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

View raw message