Linked by David Adams on Wed 14th Dec 2011 16:01 UTC, submitted by fran
Internet & Networking 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.
Database
by tony on Wed 14th Dec 2011 19:19 UTC
tony
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.

Reply Score: 3

RE: Database
by Alfman on Wed 14th Dec 2011 20:14 in reply to "Database"
Alfman 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.

Reply Parent Score: 2

RE[2]: Database
by Alfman on Wed 14th Dec 2011 20:40 in reply to "RE: Database"
Alfman Member since:
2011-01-28

Just correcting myself, php session data isn't stateless, but if load balancing drives users to the same server each request, it's not an issue. And it's easy to store on NFS otherwise.

Reply Parent Score: 2

RE[2]: Database
by fran on Wed 14th Dec 2011 22:46 in reply to "RE: Database"
fran Member since:
2010-08-06

ok I know this is not stackoverflow but is this a problem across all databases? For instance NoSql, Couchbase, SQL ect.
Is'nt there also type of cacheing plugin that make PHP faster and methods to curb output buffer flooding?

Reply Parent Score: 2

RE[2]: Database
by Dr.Mabuse on Thu 15th Dec 2011 01:26 in reply to "RE: Database"
Dr.Mabuse 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...

Reply Parent Score: 3

RE[2]: Database
by Laurence on Thu 15th Dec 2011 11:24 in reply to "RE: Database"
Laurence 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.

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.

Reply Parent Score: 2

RE[2]: Database
by tony on Thu 15th Dec 2011 18:51 in reply to "RE: Database"
tony 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.


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.

Reply Parent Score: 2

RE[2]: Database
by Lennie on Sat 17th Dec 2011 00:13 in reply to "RE: Database"
Lennie Member since:
2007-09-22

No large website uses stock PHP, they atleast use a bytecode cache like APC/eaccelerator/xcache and a cluster of memcached servers to not hit the database servers to do read-queries. Maybe a NOSQL solution like redis or whatever.

Reply Parent Score: 2