> 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.
While that's true in theory, in practice I think it's rarely the case. My
experience has been that when companies decided to move to a new version -
that's the time they did the code migration, and not a moment sooner.
Beforehand, they'd just turn off E_DEPRECATED to quiet it down. That may
not be the nice or right thing to do, but it appears to be the most popular
course of action.
That said - we can do something along the same lines here, to be nice to
those who play nice. We can issue an official 'mod_php is being deprecated'
notice when the server starts up - even as soon as 5.6 - and then actually
deprecate it in the next major version. Depending on the kind of feedback
we see, we can choose whether to actually pull it out or just keep the
deprecation warning.
Last, I think we're ignoring the fact that the work involved in actually
doing the move to FastCGI is very simple and centralized, as opposed to a
full app audit - sometimes a source code audit - that is needed when we
change constructs or function behavior. It's difficult to compare the
complexity of changing codebases of tens, hundreds and sometimes millions of
lines of code - to that of relatively minor setup issues.
> 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.
I think that if we publish it sufficiently ahead of time; Plus point the
die hards to where they can get the old mod_php; The amount of angst would
actually be much lower than some of the bigger changes we've made over the
course of PHP's history.
I find it difficult to believe that a change that can be implemented within
a couple of hours on a bad day - and with perhaps a couple of extra days to
account for scripts and monitoring configurations - would create that much
backlash. I think people will appreciate we're pushing them towards the
right choice.
> > 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 still come across a lot of sites of large companies (not the top Internet
companies, but still quite large) where Apache does end up serving at least
some of the static files. We needn't assume that every medium-large website
has experts working to squeeze every last bit of performance out of it,
since unfortunately it's not true. Also, maybe it's me but my experience is
that Apache really mishandles a situation where it runs out of processes -
so more often than not, configurations allow for a lot more processes than
may actually be needed. FastCGI/fpm seem to do a much better job at
handling a large number of requests with just a handful (or dozenful) of
processes.
> 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.
Well, I think deprecating it would be pretty convincing :)
Zeev