Feature #1608
closedrecursive stat calls busy server fastcgi entry point pretty url
Description
When using mod_rewrite to make pretty urls passed to a script, the lighttpd response.c tries to determine if the full path passed is in fact a physical path on the server.
On a busy server (1k reqs/sec) there are a large number of uncessary stat calls hindering performance.
Setup:
/var/www/entry-pointA -> PHP file
fastcgi.map-extensions = ( "entry-pointA" => ".php" )
''Example request url:'' [BR]
http://somedomain.com/entry-pointA/id/5555/age/18/date/2008-03-21/
That url gets translated into this physical path in response.c
/var/www/entry-pointA/id/5555/age/18/date/2008-03-21/
response.c recursivly checks to see if the directory exists.
In this case resulting in 7 stat() calls for a single request.
''Here is the output from strace -c, attached to the busy server for several minutes.''
Process 1618 detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 17.01 0.676998 0 2704547 2390 writev 12.58 0.500569 0 11769579 epoll_ctl 12.04 0.478999 0 8315491 5121504 stat 10.79 0.429566 0 4875013 2007864 read 8.77 0.349171 0 4459738 close 5.76 0.229066 0 3019663 open 5.40 0.214750 0 927997 927997 connect 5.21 0.207543 0 551577 epoll_wait 4.24 0.168613 0 4872873 ioctl 4.22 0.167795 0 630438 3 sendfile 3.46 0.137896 0 1855698 1855698 getxattr 3.40 0.135188 0 3051478 setsockopt 2.19 0.087194 0 927997 socket 1.21 0.048339 0 469685 14153 shutdown 1.21 0.048173 0 700550 188599 accept 1.07 0.042602 0 3412598 fcntl 0.68 0.026919 0 927977 getsockopt 0.63 0.024935 0 927977 getsockname 0.08 0.003079 1 3589 40 write 0.03 0.001253 0 102925 mremap 0.02 0.000777 111 7 unlink 0.01 0.000354 0 1337 brk 0.00 0.000000 0 111 lseek 0.00 0.000000 0 25 mmap 0.00 0.000000 0 25 munmap ------ ----------- ----------- --------- --------- ---------------- 100.00 3.979779 54508895 10118248 total
I have tried using the FAM engine to see if that helps, it does not, since these urls are not translating to actual files.
My suggestion to correct this issue, is to add a new config variable to lighttpd for web applications that operate in this manner.
Something like...
server.fastcgi-entry-points = ( "/var/www/entry-pointA", "/var/www/entry-pointB")
Where "entry-pointA" is forced as a type of FCGI app extension.
On startup of the server, it will check at that time if those fastcgi-entry-points do actually exists, and fail startup on error
Then in the response.c file, add a check to see if the physical path matches any of those entries, if it does, then we know not to recursively search if the full path exists.
Example:
check this fastcgi-entry-point - /var/www/entry-pointA
against this physical path - /var/www/entry-pointA/id/5555/age/18/date/2008-03-21/
if the beginning of the check var, matches the beginning of the physical path, we have our file
If my C skills were good enough, I would attempt to fix this myself, alas that is not the case :)
Let me know if you have any questions.
Updated by stbuehler about 17 years ago
- Status changed from New to Fixed
- Resolution set to invalid
- This is not a bug, you request a new feature.
- Why don't you just use the prefix mapping for fastcgi and disable check-local? Or fix your fastcgi app to take the path as query-string?
- Even if you had a patch, i don't think it would be accepted; it just increases complexity, and i don't see a good reason for it.
Also available in: Atom