https://bz.apache.org/bugzilla/show_bug.cgi?id=54962
--- Comment #5 from Joe Orton <[email protected]> --- 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: [email protected] For additional commands, e-mail: [email protected]
