Hi,
I have been doing a review of PHP scripting overheads in typical shared
hosting service templates. This is possibly the most commonly used
usecase for suPHP -- because service providers employ it to enforce
UID-based separation of accounts.
I've been quite surprised to find that the suPHP (/usr/lib/suphp/suphp)
execution can often take up to 25% of the execution time of the child
process, and I have drilled down into this. The major part of this
overhead is involved in the separate walking of the path and real paths
of the script to enforce the suPHP access rules (even though these are
commonly the same). This is compounded by the coding of
suPHP::Application::checkParentDirectories() which results in 4 lstat
calls per check, and as a result checking a typical script path for, say
http://somedomanin.com/test/hello-world.php
which on my test shared hosting service maps to the file
/websites/LinuxPackage02/so/me/do/somedomanin.com/test/hello-world.php
on the NFS mount point /websites/LinuxPackage02 results in some 120
lstat64/fstat64 system calls. OK, the path will have typically been
previously walked by the .htaccess scan and hence these calls are
serviced from the filesystem cache rather that remote RPC (since in this
case this NFS mount has an acregmin=15). Nonetheless, this is still 120
file system calls when perhaps 20 would do the same job with a bit of
thought.
However, I am also minded that suPHP is now effectively frozen with the
last release, version 0.7.1, being almost three years old now. So is
there any point in my proposing a patch to address this or even
discussing this further on this DL?
Regards
Terry Ellison
_______________________________________________
suPHP mailing list
[email protected]
https://lists.marsching.com/mailman/listinfo/suphp
