Project

General

Profile

Actions

Feature #1608

closed

recursive stat calls busy server fastcgi entry point pretty url

Added by complexero about 17 years ago. Updated over 16 years ago.

Status:
Invalid
Priority:
Normal
Category:
core
Target version:
-
ASK QUESTIONS IN Forums:

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.

Actions #1

Updated by stbuehler about 17 years ago

  • Status changed from New to Fixed
  • Resolution set to invalid
  1. This is not a bug, you request a new feature.
  2. 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?
  3. 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.
Actions #2

Updated by stbuehler over 16 years ago

  • Status changed from Fixed to Invalid
Actions

Also available in: Atom