Re: phpng: Refactored PHP Engine with Big Performance Improvement

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