Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39013
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain metacafe.com designates 91.198.254.7 as permitted sender)
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>, Oleg Grenrus <phadej@gmail.com>,  PHP Internals List <internals@lists.php.net>
In-Reply-To: <487DFB86.3030404@lerdorf.com>
References: <1216133436.6875.35.camel@amirh> <487CEF26.7030802@lerdorf.com>
	 <1216159988.28846.12.camel@localhost> <487D22AE.20109@lerdorf.com>
	 <5a2b1bf10807152247r563092a6l88d555d2389506e4@mail.gmail.com>
	 <9b3df6a50807160340w578d7490xb6f2810652e1bb47@mail.gmail.com>
	 <487DFB86.3030404@lerdorf.com>
Content-Type: multipart/alternative; boundary="=-NUBUi4CmtbLCRYUWwDqs"
Date: Wed, 16 Jul 2008 19:14:22 +0300
Message-ID: <1216224862.20625.33.camel@amirh>
Mime-Version: 1.0
Subject: Re: [PHP-DEV] lstat call on each directory level
From: amirh@metacafe.com (Amir Hardon)

--=-NUBUi4CmtbLCRYUWwDqs
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Wed, 2008-07-16 at 06:45 -0700, Rasmus Lerdorf wrote:

> Arvids Godjuks wrote:
> > Hello.
> >
> > I think this should be optimized.
> > I'm not an expert ofcourse, but as I understood there is only one case
> > witch need a special treatment - require/include _one when a file with
> > equal contents is included from different directories.
> > You can make a switch witch controls if lstat is made or not in these
> > cases. People who know what they are doing will switch it to off and
> > make sure their includes don't result in Fatal error (anyway, to my
> > opinion it is bad desing if such thing happens).
> > Ofcourse open_basedir users will don't have any benefit from it, but
> > that's their choise.
> > So I think you should think it out and make this optimization to 5.3
> > release. It would be great optimization, IMHO.
> 
> But all these lstats should be getting cached, so I don't see how it 
> would affect performance very much.  If you are blowing your realpath 
> cache, you need to take a look at why that is happening.
> 
> We probably should disconnect clearstatcache() from the realpath_cache, 
> and we could perhaps look at doing partial path caches through our own 
> realpath implementation.  The other thing that can suck is when you have 
> an include_path miss.  We don't cache misses like this, so if you are 
> relying on include_path to find your files and you don't hit it on the 
> first try, you are going to see a bunch of stats.  But that is again 
> something that is easily fixed by not writing crappy code.
> 
> I think that breaking code that looks like this:
> 
> require_once './a.inc';
> require_once 'a.inc';
> require_once '../a.inc';
> require_once 'includes/a.inc';
> 
> when these all refer to the same a.inc file depending on where the 
> parent file is and what the coder had for breakfast that morning would 
> be a very bad idea.
> 
> -Rasmus
> 


Since the realpath cache is only relevant for a single request(right?),
removing these lstats
 calls will a major benefit.

Before moving our portal dir to the /  dir, ~40% of our page requests
were slow on the server side (I'm not sure if my company policies allow
me to expose exactly what is considered slow),
after moving it ~20% of the page requests were slow! this is
significant.
And there are still many lstat calls made inside our portal's directory
tree.

So I think that a  php.ini directive for switching off these lstats
which will be off by default,
will be a great thing.

-Amir.

--=-NUBUi4CmtbLCRYUWwDqs--