https://bz.apache.org/bugzilla/show_bug.cgi?id=54962

--- Comment #5 from Joe Orton <jor...@redhat.com> ---
The problem here is that we're calling fstat() again for every request in the
critical path of serving a GET request.  I don't know how much performance
difference this will make on a modern server, but assume it is non-zero.

If we're going to do this it should be right after the open() so the mtime used
is using correct stat data as well (and etag).

The trade-off is whether we should fix correctness for an edge case, but make
everybody take a performance hit.

I think it should be possible to offer a "fast" equivalent of the default
handler, i.e. without the extra fstat(), with some option/config tweak applied,
BUT:

1. we can only do so by omitting Last-Modified, etag, and content-length, since
all may be using stale stat data from the directory walk.  

2. we could not use the FILE bucket, which needs a determinate length (hence
requires stat data), so we would lose the performance benefits sending the
content via mmap() or sendfile() etc so it might not actually be faster (I have
no idea)

3. for small files without a C-L, the content-length filter will still be able
to generate a content-length even by reading till EOF, but not for larger
files, so there is a performance/network efficiency hit here too.

I tend towards saying we should fix correctness at the cost of performance
regardless, and probably the second-fstat-less path isn't worth the
complexity/costs.

(The "proper" solution is to open the file then fstat in the dirwalk, then use
the fd in the default handler, I have no idea how we can do it without huge
hacks or some redesign of the core hooks, since we don't know which handler
will be used in the dirwalk.  I may be missing other fundamental things.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

Reply via email to