Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65999
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ellisons.org.uk from 79.170.44.47 cause and error)
Message-ID: <512405F2.4040505@ellisons.org.uk>
Date: Tue, 19 Feb 2013 23:08:34 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: Brendon Colby <brendon@newgrounds.com>, 
 Rasmus Lerdorf <rasmus@lerdorf.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAHHbRnEUVcGqH6+++CWXM6XWobJn5MzKxLdfX9RHxoJ0uXaZdg@mail.gmail.com> <51229088.90306@lerdorf.com> <5122DA51.6090606@sugarcrm.com> <5122DBA9.2010004@lerdorf.com> <5122E00F.80409@sugarcrm.com> <5122E451.1040308@lerdorf.com> <51234789.4030405@ellisons.org.uk> <5123A2FE.1050101@ellisons.org.uk> <5123E152.2050600@sugarcrm.com>
In-Reply-To: <5123E152.2050600@sugarcrm.com>
Content-Type: multipart/alternative;
 boundary="------------020607060806080306020806"
Subject: Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
From: Terry@ellisons.org.uk (Terry Ellison)

--------------020607060806080306020806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 19/02/13 20:32, Stas Malyshev wrote:
> Hi!
>
>> and IIRC mwiki does 4 of these on a page render.  Here a pattern based
>> on (@include($file) == 1) is more cache-friendly.
> This goes back to the fact that @ does not really disable errors - it
> only disables reporting of the errors, but the whole message is
> generated and goes all the cycle up to the actual error reporting before
> being suppressed. I've tried to address this problem a number of times
> but looks like there's really no way to do it without sacrificing some
> parts of current error reporting such as track_errors.
Yup, in this scenario we're trading off two things.  What the pattern is 
saying  is if the source file exists then compile it. However, if the 
file exists, in say 90+% of the cases, and the code is often cached then 
the file_exists check generates I/O that isn't needed if the file is 
already APC (or O+ / xcache) cached.  Yup if the file is missing then 
the error is generated and trapped in the reporting cycle, but the final 
result is that the result is false and the false==1 fails.  Other than 
the wasted cycles in running up this stack, there aren't any other 
side-effects that I am aware of. Are there any?

Yes, this is an overhead, but it is small beer compared to doing a 
getattr() RPC across the server room fabric to a NAS server backend.
>> So in summary, this is largely avoidable but unfortunately I don't think
>> that we can persuade the dev team to address this issue, even if I gave
>> them the solution as a patch :-(
> Could you explain what you're talking about here?
The fact that you are engaging in this dialogue is great and I really 
appreciate it.  What I am still trying to work out is how to interact 
with you guys in a way that is mutually productive.  I did make the 
mistake of choosing the mainstay stable version iN live prod systems use 
-- 5.3 -- to take this whole issue apart and I guess that the dev team 
regards this as history.

I guess that I should bite the bullet and switch to 5.5.  I've been 
working on an evaluatorfork of APC optimized for CLI/GCI which tackles a 
lot of these issues head on and performs reasonable well, but I realise 
that this is a dead-end and will never get deployed, but I am currently 
considering regressing some of this technology into 5.5 and O+.  Are you 
interested in a version of O+ which supports all SAPIs?

In architectural terms I feel that having a universal cache option is 
important.  It changes the mindset from something which is only used in 
niche performance use cases to a standard option.  It also means that 
the cache can be stress tested by the entire php test suite.  However, 
to do some of this you don't start with a patch, but with an RFC 
informed by evidence, and that's my real reason for doing this demonstrator.

//Terry

--------------020607060806080306020806--