> -----Original Message-----
> From: Rasmus Lerdorf [mailto:[email protected]]
> Sent: Thursday, May 08, 2014 7:00 PM
> To: Zeev Suraski; Andrea Faulds
> Cc: Andi Gutmans; Sebastian Bergmann; [email protected]
> Subject: Re: [PHP-DEV] phpng: Refactored PHP Engine with Big Performance
> Improvement
>
> On 5/8/14, 5:48 AM, Zeev Suraski wrote:
> > Again, this is just history/habits.
> > Nothing prevents creation of apache-fastcgi-php5 package that'll do
> > the exact same thing using FastCGI.
>
> What you are calling history/habits here is also knows as operational
> stability.
> Every change to a stack incurs operational costs which has to be balanced
> against the benefits of changing a component. Even though it seems like a
> trivial
> thing to change from Apache/mod_php to Apache/mod_fcgid or nginx+php-
> fpm, the operational cost can be quite high. Consider changes to the
> Nagios
> monitoring setup. Dev VM images all have to be updated.
> Startup/shutdown/deploy and logging systems might be affected along with
> integration tests. And for most environments changing doesn't actually buy
> you
> anything. A typical PHP request spends so little time in the web server
> compared
> to waiting on mysql and memcache replies that even a major performance
> boost
> doesn't actually give you much.
Two things:
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.
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.
> I fully agree that nginx+php-fpm is a nicer architecture. I like the
> process
> separation that fastcgi brings and the saner and richer configuration
> nginx brings
> along with the slight performance boost, but even for my own use those
> benefits haven't outweighed the cost of switching for me for systems that
> are
> running well under mod_php today.
The question is whether that cost doesn't become marginal as you assess the
cost of moving to the next major version of PHP, as I'm obviously not
arguing we do this in 5.x. I don't think people generally expect to just
'yum update' and be done with it when they deal with a major version of PHP.
Now, I'll be the first person to admit (and wholeheartedly argue) that
compatibility breakage adds up as opposed to being boolean and must be
minimized - but I think the benefits here far outweigh the costs. We've
done much more painful transitions.
I view mod_php as a relic of the past which served its purpose. Same goes
to all other server-specific SAPIs. It's time to move on.
My 2c.
Zeev