Re: lstat call on each directory level

From: Date: Wed, 16 Jul 2008 05:47:28 +0000
Subject: Re: lstat call on each directory level
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-38997@lists.php.net to get a copy of this message
There is apc.include_once_override Optimize include_once() and require_once() calls and avoid the expensive system calls used. and apc.stat Be careful if you change this setting. The default is for this to be On which means that APC will stat (check) the script on each request to see if it has been modified. If it has been modified it will recompile and cache the new version. If you turn this setting off, it will not check. That means that in order to have changes become active you need to restart your web server. On a production server where you rarely change the code, turning stats off can produce a significant performance boost. For included/required files this option applies as well, but note that if you are using relative path includes (any path that doesn't start with / on Unix) APC has to check in order to uniquely identify the file. If you use absolute path includes APC can skip the stat and use that absolute path as the unique identifier for the file. You might try APC. It stats, but not so much On Wed, Jul 16, 2008 at 1:20 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote: > Lars Strojny wrote: >> >> Hi Rasmus, >> >> Am Dienstag, den 15.07.2008, 11:40 -0700 schrieb Rasmus Lerdorf: >> [...] >>> >>> That's a realpath() call and it should be getting cached by the realpath >>> cache, so if you are seeing these on every request, try increasing your >>> realpath_cache size in your .ini. Without checking the realpath, you would >>> be able to circumvent open_basedir checking really easily with a symlink. >> >> Couldn't we do that check only if open_basedir is active? > > Like I said, it is used for other things too, like include_once filename > resolution. Check the code. > > -Rasmus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Oleg Grenrus

« previous php.internals (#38997) next »