Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65927
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: <51234789.4030405@ellisons.org.uk>
Date: Tue, 19 Feb 2013 09:36:09 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: Stas Malyshev <smalyshev@sugarcrm.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>
In-Reply-To: <5122E451.1040308@lerdorf.com>
Content-Type: multipart/alternative;
 boundary="------------060409080804070804000604"
Subject: Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
From: Terry@ellisons.org.uk (Terry Ellison)

--------------060409080804070804000604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The point that this thread highlights is that apps developers / 
administrators at both ends of the scale -- the enterprise and the 
shared service user -- normally have little say over the infrastructure 
architecture on which their application runs.  In both these cases the 
infrastructure will be hosting 100s if not 1000s of apps, and the 
environment cannot be tailored to any one app.  So issues like storage 
architecture and security architecture (e.g. UID-based enforcement of 
app separation) are a given as NFRs (non-functional requirements). Use 
of NFS with server / storage separation is still a standard 
implementation design pattern, when enterprises require simple-to-manage 
scalability on these tiers.  We aren't going to change this, and neither 
will the O/P.

Surely PHP will achieve better penetration and the greater acceptance if 
it can offer more robust performance in this sort of environment?
> Sure, but then you can go with something like Redis.
>
> But, again, if you go back to the original question, this has nothing to
> do with often-changing data in a couple of PHP include files:
>
>    We have several Apache 2.2 / PHP 5.4 / APC 3.1.13 servers all serving
>    mostly PHP over NFS (we have separate servers for static content)."
>
> So they are serving up all their PHP over NFS for some reason.
>


--------------060409080804070804000604--