httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: cvs commit: httpd-2.0/server request.c
Date Fri, 09 Nov 2001 16:42:33 GMT
FWIW, I see two stats rather than three to fetch c:/website/file500.html (an improvement).

The first is:
core_translate()
apr_filepath_merge()
apr_stat()

The second is:
core_map_to_storage()
apr_lstat()
apr_stat()

Haven't dug into the code but is there a safe way to eliminate the filepath_merge or is
this something required on Windows (in which case perhaps the results can be cached).

Bill

----- Original Message -----
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: <dev@httpd.apache.org>; <stoddard@apache.org>
Sent: Friday, November 09, 2001 11:30 AM
Subject: Re: cvs commit: httpd-2.0/server request.c


> From: "Greg Ames" <gregames@remulak.net>
> Sent: Friday, November 09, 2001 10:15 AM
>
>
> > wrowe@apache.org wrote:
> > >
> > > wrowe       01/11/09 00:08:43
> > >
> > >   Modified:    server   request.c
> > >   Log:
> > >     Reintroduce the 'one stat dir_walk'
> >
> > Bill,
> >
> > How confident are you that this is rock solid?  i.e., should I consider
> > bumping it into 2.0.28?  It would be great if we could have the
> > performance benefit, but IMO stability is the top priority for a beta
> > candidate tarball.
>
> Agreed that stability is key - and this is optimization, not essential.
>
> However, I don't mind incorporating it into .28.
>
> > Bill S. said he'd test it on Win32.  I can test it on Linux and FreeBSD.
>
> Please, do.  Then let's draw it up for a few hours on apache.org to really
> pound on it.
>
> It is entirely possible this introduces a hole, but I doubt it.  I see about
> five cases that it could cause trouble... then I rewalk the code and realize
> that they are already protected against.  Thinks like skipping the final stat,
> well, we already glom the final stat outside of that loop.
>
> Come to think of it, the only scenario I can picture is;
>
>   user requests a symlink (the final filename component)
>   we stat -> optimize
>   the loop gets down to that last element/symlink
>   we optimize away the actual stat to the target file
>
> That's badness, but it's the only scenario I can picture.  What if we take
> it a step further, and test 'is this the end?' before we go and skip that
> last lstat.  In this case, we can skip the lstat, but we musn't skip the
> actual stat.
>
> Stat'ing the final target, rather than lstat'ing it, is no good, we would end
> up with a stat - lstat - stat sequence that is a waste.
>
> Bill
>
>
>


Mime
View raw message