On 5/8/14, 2:24 PM, Zeev Suraski wrote:
> 1. You're right it buys operational stability; But then, people who'll go
> on a major PHP version upgrade will expect some level of operational
> instability (we should hope so at least, because they'll probably get it).
> App breakages are an order of magnitude (or two or three) more painful than
> relatively simple changes to monitoring tools or administrative scripts.
We tend to provide very good forward compatibility with E_DEPRECATED
warnings and a detailed UPGRADING document. This means you can prepare a
codebase for the next major release well ahead of time and run it in
production on the previous version while it is easy for the developers
to run a newer PHP version on a dev vm to make sure everything gets
caught. At the point of the upgrade it becomes quite painless. That is,
the work is nicely spread out and there is no jarring company-wide
disruption since all app breakages have been pre-fixed.
When swapping out an infrastructure element like the web server or at
least an architectural aspect of the web server, it is something that
touches a lot of moving parts and hits not just the dev team but also
the test and ops teams quite hard. It is hard to prepare for because you
don't really know if you missed something until you swap out the
production implementation that is running at scale. So the angst
involved is much higher.
> 2. I never argued that FastCGI/fpm is faster than mod_php; It's probably
> not (it's roughly as quick from my experience). But it's *a lot* more
> scalable (in terms of in-machine scalability), since it breaks the 1:1
> mapping between Apache processes and PHP processes. Often, for a typical
> setup of with hundreds of Apache children, you could use just several dozen
> PHP processes when using FastCGI. With mod_php, after a short while you'd
> have each Apache process consume a dozen or more megabytes of memory - times
> hundreds of processes that's a lot of memory; With FastCGI, you'll only
> have several dozen processes consuming that much memory, while the Apache
> processes can stay lean. Not to mention you get to use more efficient
> mpm's, ones mod_php doesn't support - and save even more memory. With
> requests growing shorter, simpler while also rapidly growing in frequency -
> this sort of density is very important IMHO.
Yup, I don't disagree that it is a more efficient model, especially for
smaller shops that don't have the luxury of using CDNs and having
multiple server pools for different purposes. However, for larger sites,
every request that makes it through to the Apache+mod_php process tends
to be an actual heavy PHP request. Static files aren't handled by that
pool of servers. In that scenario the server density differences between
FastCGI and mod_php becomes much smaller. If every request is heavy you
are going to need the same number of each. You gain a bit by not having
the Apache piece in each PHP process, but it isn't all that significant
and when weighed against the operational cost of switching it doesn't
seem all that attractive. I would love to be able to convince sites like
that to switch, but I haven't been able to come up with enough technical
benefits to outweigh the operational costs yet.
-Rasmus
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc