Return-Path: 
 <new-httpd-return-18263-apmail-new-httpd-archive=apache.org@apache.org>
Delivered-To: apmail-new-httpd-archive@apache.org
Received: (qmail 51154 invoked by uid 500); 1 Aug 2001 17:51:23 -0000
Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
list-help: <mailto:new-httpd-help@apache.org>
list-unsubscribe: <mailto:new-httpd-unsubscribe@apache.org>
list-post: <mailto:new-httpd@apache.org>
Delivered-To: mailing list new-httpd@apache.org
Received: (qmail 51140 invoked from network); 1 Aug 2001 17:51:23 -0000
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <114401c11ab2$348fe170$93c0b0d0@roweclan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <new-httpd@apache.org>
References: <3B33B2B2.40800@pacbell.net>
Subject: Re: directory_walk performance
Date: Wed, 1 Aug 2001 12:48:32 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
Status: O
X-Status: 
X-Keywords: 
X-UID: 20

Brian,

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

  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 :)

Bill
  

----- Original Message ----- 
From: "Brian Pane" <bpane@pacbell.net>
To: "new-httpd" <new-httpd@apache.org>
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
> 
> 
>