Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66061
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: <5124E4F7.1070509@ellisons.org.uk>
Date: Wed, 20 Feb 2013 15:00:07 +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> <512405F2.4040505@ellisons.org.uk> <512488D2.6060006@sugarcrm.com>
In-Reply-To: <512488D2.6060006@sugarcrm.com>
Content-Type: multipart/alternative;
 boundary="------------080903090107040803040900"
Subject: Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
From: Terry@ellisons.org.uk (Terry Ellison)

--------------080903090107040803040900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 20/02/13 08:26, Stas Malyshev wrote:
> That depends of what your error handlers do. Some may write to log 
> files, etc. if not configured properly (since error_reporting setting 
> doesn't have to be considered in it). IIRC, for most of the cases O+ 
> should be able to resolve all includes/requires on cached files 
> without syscalls - but file_exists is a different matter since caching 
> it in generic case can be very dangerous. 
I am not suggesting caching file_exists but rather encouraging coding 
patterns which avoid its use /if/ the application is intended to give 
good cached performance -- e.g. apps like mwiki, wordpress and drupal.

>> 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?
> I think right now O+ can support CLI (provided enable_cli is set) but
> for most cases it's kind of useless since scripts are rarely re-included
> in common CLI scenarios. So if you know how to improve common CLI
> scenarios it may be interesting, though I imagine it's not the most
> common use case. But if it adds there without problems for anything
> else, why not.
Let me get a dev stack for 5.5 and O+ up and then I can comment on 
this.  As far as APC's support for CLI goes -- the cache doesn't connect 
to the apache2 SMA even if you run the cli process in the same UID, and 
since the SMA gets released when the process count goes to zero, caching 
doesn't really do anything as the cache discarded between cli 
executions, so if practice you always run uncached.

As to the frequency of the use case, maybe not in the case of cli, but 
cgi is still tremendously common, as shared hosting providers still need 
to implement UID-based separation of scripting environments for 
different user accounts.  There are still significant scaling issues 
with php-fpm in this usecase, so only a few SHPs offer FastCGI support 
and then only as a premium option. BTW, I saw that you recommended in 
one of your blog posts that you to use a bytecode cache if you care 
about performance should do. However, a lot of app maintainers who use a 
shared hosting service do care about performance but don't have this as 
an option :-(

For example with my cli-based LPC opcode cache, I can do a series of  
"make test" runs (1) with the opcache disabled; (2) with it enabled but 
the cache empty and (3) with it enabled and the cache(s) primed.  
Ideally all three (*) should give the same test results, and this gives 
you confidence that the cache is working properly.  I would like to do 
this with APC or O+, but in practice AFAIK, I can't do (3) so how do I 
or the developers know what PHP and extension features aren't being 
supported / working properly when the code is cached?

(*) With the tests as currently written, some fail with case (3) because 
the runs are missing compiler warnings which are only generated if the 
code isn't cached (and in case of my cache at its current build quite a 
few fail because it still doesn't play nicely with other extensions like 
phar.)

--------------080903090107040803040900--