Linked by David Adams on Wed 14th Dec 2011 16:01 UTC, submitted by fran
PHP's popularity and simplicity made it easy for the company's developers to quickly build new features. But PHP's (lack of) performance makes scaling Facebook's site to handle hundreds of billions of page views a month problematic, so Facebook has made big investments in making it leaner and faster. The latest product of those efforts is the HipHop VM (HHVM), a PHP virtual machine that significantly boosts performance of dynamic pages . And Facebook is sharing it with the world as open-source.
Thread beginning with comment 500111
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Member since:2011-01-28
Well, the front end PHP servers are usually (always?) stateless, which means they can be scaled trivially by running clusters of mirrored web servers in parallel. The same sort of scalability is not nearly as trivial for databases, and for that reason they tend to be much more problematic.
However that said, PHP is extremely inefficient. It's worse than java or .net by a factor of roughly 100 according to the "average" row in the following benchmark:
http://www.csharp-architect.com/images/benchmarksJan2009Final.gif
So, with some hand-waiving, we'd expect a VM version of PHP to significantly reduce the quantity of PHP servers required to service a given load, and the excess servers no longer needed could be redeployed as less heavily loaded database servers.
This makes a lot of sense for an entity like facebook and shared hosting providers where they run servers at max capacity.
Member since:2011-01-28
Member since:2010-08-06
Member since:2009-05-19
However that said, PHP is extremely inefficient. It's worse than java or .net by a factor of roughly 100 according to the "average" row in the following benchmark: ... (snip)
Most Java applications, in my experience, running in a web environment are horrible, simply horrible, memory hogs. I can think of many examples, commercial and internally developed that fit this description!
Maybe it's not Java's fault per-se, but the toolkits, or the methodology behind them, I really don't know (or care), but I cannot hope to recall the amount of times Tomcat has balked because it's run out of resources. Servers running this software nearly always need more ram, and more cpu than their PHP/Apache2 counterparts.
Maybe the VM powering PHP really is that much slower, but when considering the complete stack to deliver content to the web, PHP is a much better option if you actually care about reliability and, I think, user-perceived performance.
Just my 2 cents...
Member since:2007-03-26
Well, the front end PHP servers are usually (always?) stateless, which means they can be scaled trivially by running clusters of mirrored web servers in parallel. The same sort of scalability is not nearly as trivial for databases, and for that reason they tend to be much more problematic.
However that said, PHP is extremely inefficient. It's worse than java or .net by a factor of roughly 100 according to the "average" row in the following benchmark:
http://www.csharp-architect.com/images/benchmarksJan2009Final.gif
So, with some hand-waiving, we'd expect a VM version of PHP to significantly reduce the quantity of PHP servers required to service a given load, and the excess servers no longer needed could be redeployed as less heavily loaded database servers.
This makes a lot of sense for an entity like facebook and shared hosting providers where they run servers at max capacity.
However that said, PHP is extremely inefficient. It's worse than java or .net by a factor of roughly 100 according to the "average" row in the following benchmark:
http://www.csharp-architect.com/images/benchmarksJan2009Final.gif
So, with some hand-waiving, we'd expect a VM version of PHP to significantly reduce the quantity of PHP servers required to service a given load, and the excess servers no longer needed could be redeployed as less heavily loaded database servers.
This makes a lot of sense for an entity like facebook and shared hosting providers where they run servers at max capacity.
I can't see any figures for PHP in that gif.
I'd also be interested to see PHP compared against CGI, mod_perl and Python.
Member since:2005-07-06
Well, the front end PHP servers are usually (always?) stateless, which means they can be scaled trivially by running clusters of mirrored web servers in parallel. The same sort of scalability is not nearly as trivial for databases, and for that reason they tend to be much more problematic.
However that said, PHP is extremely inefficient. It's worse than java or .net by a factor of roughly 100 according to the "average" row in the following benchmark:
http://www.csharp-architect.com/images/benchmarksJan2009Final.gif
So, with some hand-waiving, we'd expect a VM version of PHP to significantly reduce the quantity of PHP servers required to service a given load, and the excess servers no longer needed could be redeployed as less heavily loaded database servers.
This makes a lot of sense for an entity like facebook and shared hosting providers where they run servers at max capacity.
However that said, PHP is extremely inefficient. It's worse than java or .net by a factor of roughly 100 according to the "average" row in the following benchmark:
http://www.csharp-architect.com/images/benchmarksJan2009Final.gif
So, with some hand-waiving, we'd expect a VM version of PHP to significantly reduce the quantity of PHP servers required to service a given load, and the excess servers no longer needed could be redeployed as less heavily loaded database servers.
This makes a lot of sense for an entity like facebook and shared hosting providers where they run servers at max capacity.
Those functions in the benchmark, how often is PHP required to do computationally complex operations? Most of the time it's rendering HTML and pulling data from or pushing into a database. Very simple stuff. We're not calculating Pi to the millionth digit or calculating jump coordinates with PHP. I can't imagine you see any difference in a basic web page with a DB back-end using PHP or compiled C.
And Java has always seemed slower to me in implementation. Such a resource hog, and what's worse as a sysadmin I have very little idea of what's going on inside the Java engine. Neither do the developers, either it seems. So when stuff goes wrong, it goes way wrong.
Member since:2007-09-22
Member since:
2005-07-06
For most of the sites I've worked with that use PHP, the bottleneck wasn't PHP, but the database back-end. I wonder what point you get to when PHP is actually the bottleneck.