I was surprised to learn today that PHP is used widely in high-traffic websites.

I always thought that PHP is not strong in terms of performance, being a dynamic, scripting language (e.g. compared to statically typed, compiled language like C/Java/C# etc.).

So how come it performs so well?

+2  A: 

It doesn't, which is why there are projects like HipHop, but dynamic languages are often faster to develop in, and hardware is cheaper than developers.

David Dorward
+2  A: 

It doesn't really perform "so well", just well enough to be used. Keep in mind, though, that Java and C#.NET are also run as bytecode inside a VM. PHP, with tools such as Zend Optimizer, can also skip the compilation step and run as bytecode.

PHP will not run as fast as native, compiled C code, but websites such as Facebook compile PHP to C++ to make it run faster (see HipHop-PHP).

Actually, it's impossible to run C# as bytecode with the default .NET distribution - it's always JIT-compiled to native machine code. While Java can be run as bytecode, it typically is also JIT-compiled.
Joel Mueller
Java and C# execute as machine code in these modern days.
Zan Lynx
+22  A: 

What you'll usually find is that it's not as slow as you think. The reason a lot of sites are slow is because the hosts are overloaded.

But one primary benefit of PHP over a compiled language is ease of maintenance. Because PHP is designed from the ground up for HTTP traffic, there's less to build than with most other compiled languages. Plus, merging in changes becomes easier as you don't need to recompile and restart the server (as you would with a compiled binary)...

I've done a considerable amount of benchmarks on both, and for anywhere under about 50k requests per second (based upon my numbers) there really isn't a significant gain to using a compiled binary (FastCGI). Sure, it's a little faster using compiled C, but unless you're talking Facebook level traffic, that's not really going to mean significant $$$. And it's definitely not going to offset the relatively rapid rate of development that PHP will afford in comparison to using C (which more than likely will require many times the code since it's not memory managed)...

PHP, if properly written can be quite scalable. The limiting factors are typically in your database engine. And that's going to be a common factor no matter what technology you use...

With regards to Facebook... they've developed a PHP to C++ converter... so really, most of their site *is* running on C++.
True, however most of their source code is written in PHP. So it's a gray area as to what it's running (It's a compiled binary, but then again it's also PHP... It provides the best of both worlds). And as I said above, they have a traffic level that will provide significant gains by switching from an interpreted server (PHP) to a compiled server (PHP->C++->G++->binary)...
It's a bit of a straw-man argument to compare PHP webdevelopment to C webdevelopment and then conclude (quite obviously) that PHP is better for it and thus non-compiled is better than compiled for webdevelopment. What does the comparison look like for a compiled language suitable for webdevelopment, like C# with ASP.NET MVC?
That's if you consider ASP.NET suitable for web development ;-)...
Well, I realize you're being tongue-in-cheek here, but none of the drawbacks of doing webdevelopment with C apply to web development with C# and ASP.NET MVC. And I do mean MVC here, as I don't like regular ASP.NET all that much.
Well, that's true. And I never said that ASP.NET was bad (aside from my joke comment). What I said was that in terms of the performance of the language, there's very little offsetting PHP from the other languages. If you want to choose an appropriate platform, you'll need to look into more than just performance (Unless you have facebook levels of traffic). One example is licensing cost. Put bluntly, ASP.NET is significantly more expensive to run for a mid-level traffic site (anything needing more than 1 server) than it would be for PHP/Linux). But there's no clear-cut "one is better"...
+3  A: 

Java deployments in a big enterprise setting are a mess...fighting with builds and code that might not compile for the slightest little things. Also, PHP runs on a fairly simple setup server-wise, not the bulky code that is Weblogic (or others), so others are right in that it's low cost to develop and cheap to deploy on several different machines. It certainly didn't help that I was soured by working in a large, VERY inefficient corporate setting while doing Java....

I wouldn't say that PHP developers are cheaper per se (I make more now as a PHP developer than I did as a Java UI developer) but I do know that my last employer paid me for a not-insignificant amount of time spent configuring, deploying, compiling, etc that is not required in PHP. We're talking probably one day/week of related configuration fussing due to new branch roll outs or release-related configurations. So, the extra I'm paid now is made up for by a significant amount more code that I'm able to work through each week.

PHP is certainly being helped by the fact that MySQL and Postgres (to a smaller extent) have become so much more powerful. They're not directly linked, but having that as a common pairing just sweetens the deal for those making decisions.

+1 "fighting with builds and code that might not compile for the slightest little things"...
+2  A: 

Most websites have performance bottle necks when querying a database etc. The amount of time the script spends executing is usually small compared to this. Using things like libmemcached can help mitigate this.

+2  A: 

Many sites started as low-traffic sites. Once you have your PHP website running and suddenly you have to handle much higher traffic, it's cheaper just to buy more servers than to rewrite your app from PHP to something else. Moreover there are tools that improve PHP performance.

Also note, that there are other factors: database, caching strategy which affect performance more than PHP itself.


In my opinion the stateless nature of PHP is the most important factor to it's scalability. It's been a while since I've done any web work with Java/ASP.NET, but I recall that both technologies have a central application "engine" that all requests are piped through. That's great, because information and state can be shared between instances, and a lot of bootstrapping (reading configuration files, connecting to databases, etc) can be done once, and then shared among instances. It's bad though because that central "engine" itself becomes a bottleneck for the whole application.

The lack of a central engine in PHP also means scaling your application is usually a simple matter of adding another web server to your rig (although scaling the database along with it is more complicated). I imagine scaling a Java/ASP.NET application is a good deal more complicated, and they reach a saturation point where adding more hardware gives less of a boost each time.

You have *no* idea what you are talking about!!!
Nate Zaugg
I would *love* to hear how I'm so wrong.