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.
