Home » Php » performance – Why is PHP apt for high-traffic websites?

performance – Why is PHP apt for high-traffic websites?

Posted by: admin April 23, 2020 Leave a comment


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?

How to&Answers:

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…


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.


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.


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).


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.


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.


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.