httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: cvs commit: httpd-2.0/server request.c
Date Mon, 08 Oct 2001 16:48:15 GMT
> wrowe       01/10/06 14:52:29
> 
>   Modified:    server   request.c
>   Log:
>     A major overhaul to the -replacement- ap_directory_walk logic.  This still
>     doesn't activate that code, I will do so probably by Monday, after more
>     thorough testing.
>   
>     Introduces the ap_directory_walk::cache so we can stop wasting tons of
>     effort in mod_autoindex and other subreq/redirect requests.
>   
>     This isn't thoroughly tested, I've only stepped through a half dozen
>     common cases.  If you want to play, define REPLACE_PATH_INFO_METHOD.

With a bit further testing, it seems this code replacement code is correct.
There is a matter of UNC paths, which I've found two bugs within, but it
should be ready to go on Unix, and essentially works on others.  [A little
more looping through sub-components of root objects would be good, but with
only '/' roots on Unix, we don't need to wait.]

I have a few more optimizations to apply, and Brian Pane is working on his
own set of optimizations as well.  I'd like to go ahead today and remove the
old directory_walk/path_info implementation, then begin optimizing so we can
determine which optimization breaks things, if any.

The first optimization to all three _walk()ers improves cache reuse, by 
returning the end product, if the base section used last time (the cached
r->per_dir_config) matches the current base (r->per_dir_config.  Right now 
that case remerges the base and cumulative result.  That made sense for the
second location_walk (the first case I implemented) but not for all these
subreq/redirect things.

The next optimization for dir_walk will cache all apr_lstat()->apr_stat() 
symlink tests, for reuse during subsequent walks (subreq/redirect).  Also,
will perform FirstBill's desired single-stat() test up front, if the rest
of the path matches from a prior request.

The next optimization will simply avoid the lstat()->stat() in the indicated
block of code [XXX: Optimization required], where we allow all symlinks, can
trust ENOTDIR and have some hint the path exists, e.g. there is a <Directory >
entry for it.

Well, it's got more work, but I'd like to see us start tracking this work as
of this point in time.  Votes --- should we activate now, or deal with all 
these optimizations and then activate that code?

[Thank you Ryan Morgan for testing this new codepath, and detailing a pair 
of compiler emits I'm fixing now :]

Bill




Mime
View raw message