Accueil / PHP Performance: "fast enough" and improving

PHP Performance: "fast enough" and improving

There has been a decent amount of chatter lately about benchmarking various frameworks and programming languages, and people often wonder how PHP stacks up. As the most widely used programming language on the web, PHP performance has a huge impact on the speed of the internet as a whole. While many people believe that PHP is slow, or that it’s not the right choice for the enterprise for performance reasons, this is demonstrably false.

First let’s talk about benchmarks. If you look at the latest data from TechEmpower, you will see that PHP does quite well. It’s on par with node.js, and easily beats out many other popular frameworks built on interpreted languages (e.g. Rails and Django). PHP is never going to compete with the performance of a compiled language like Go or Java, and it’s not trying to. On the spectrum of interpreted web languages, raw PHP excels. I say “raw PHP” because as you can see in the table, there are plenty of frameworks that add a huge amount of overhead and slow PHP way down. Similarly, when you look at comparisons of various PHP frameworks, it is clear that there is a huge discrepancy between the fastest and slowest options. If you are going to run PHP in a large scale environment, picking the right framework (or rolling your own) is critical to building a fast application. That said, performance isn’t the only thing that matters for an application, and the benefits of a feature-rich framework can outweigh the performance costs in certain cases. Today's production hosting environments also include a host of technologies (caching, ESI, reverse proxy, etc.) and optimisations that radically improve live application performance.

PHP performance also continues to get better with every release. PHP 5.3 was ~20% faster than 5.2, and 5.4 showed a 20-40% improvement over 5.3. Then with PHP 5.5 we got a bundled opcode cache, which has a dramatic positive impact on PHP’s out of the box performance, and removes the necessity of installing APC. The core PHP developers care deeply about performance, and the consistent improvements from version to version show that this will continue to be an area of focus going forward.

Perhaps most importantly, for a typical web application PHP is simply not the bottleneck. Most websites connect to networked resources to get the majority of their data (e.g. memcached, redis, MySQL or another datastore), and those resources typically govern the runtime of the page. I’ve worked on the performance team for multiple companies running large, monolithic PHP applications, and the database has always been the primary focus of our optimization efforts. Projects to reduce round trips across the network, optimize queries, and restructure data have always yielded much bigger gains than micro optimizations within PHP.

PHP is a language that optimizes for speed of development, not speed of execution. If you are working in an environment that requires extremely low latency backend performance, or one that will be running across thousands of servers and needs to be very conservative with CPU consumption, then PHP is likely not the best choice for you (or you should consider HHVM – works great with Drupal!). If, however, you are like the hundreds of millions of other websites on the internet that talk to a database, serve HTML, and need to ship features quickly, then PHP’s performance is certainly not going to hold you back. The ultimate decision about which language you use to build your application needs to consider many factors, but when you are going down the list you should put a checkmark next to PHP in the “fast enough” column.

Editor's note: This post has been updated. A direct reference to Symfony2 was removed in favor of considering the broad landscape of PHP and PHP frameworks.

Commentaires

Posted on by Juan Lopez (non vérifié).

"raw PHP" vs "many other popular frameworks built on interpreted languages (e.g. Rails and Django)"

I can't see how is this a valid comparision

Posted on by Jonathan Klein.

Hi Juan,

I agree that this comparison isn't completely apples to apples, but keep in mind that "raw Python" and "raw Ruby" don't mean a whole lot on the web. I was trying to compare the most frequently used options, while explicitly acknowledging that PHP frameworks add a significant amount of overhead.

If you look at the single query and multiple query benchmarks for just PHP, Ruby, and Python based options, raw PHP and a few PHP frameworks beat out every Python and Ruby option.

At the end of the day this article is about PHP's performance under a number of use cases, so I think it's fair to compare a few of them with other popular options for building web applications.

Posted on by Robert Colburn.

There tends to be two ways to measure backend performance: "time to perform X", or "number of performances of X per time frame". For example: time to render complex web page, or complex web pages rendered per minute. I think PHP can continue to excel in the former ratings, but I think architecturally that latter becomes an issue. This is especially true when you have high rates of concurrency.

Large-Scale PHP apps (ahem, and Drupal is no exception here) tend to consume a hefty portion of memory… per thread. Since, the LAMP model is one thread per connection, the connections tend to stack up. So, for a large scale app, you need to scale your resources. The comparison then is how many servers does it take to scale my app to my user-base

Many platforms are now basing themselves around Event Loops. Keeping a single application thread, and handling IO and/or compute intensive tasks off-thread. The result is that you can theoretically keep the server from consuming as much memory per connection. That's the theory anyway, it's still very much up to the application to manage memory efficiently.

In this regard, I believe HHVM (when it's ready!) will help tremendously help the long-term health / viability of the platform. HHVM heavily addresses compute performance, but also addresses memory usage at scale. Event Loops and VM's have their own memory usage, but it will be interesting to see large-scale Drupal deployed on HHVM.

You are spot-on about the database / backend services being the typical bottle-neck. I think we are in good times though, as we're seeing a lot of innovation in scaling databases even good ol' mysql.

Sorry, can't resist tech note:
* Java is not technically "compiled". It is compiled into byte-code, which is interpreted by the Java VM, which involves a JIT similar to other interpreted languages. This is further complicated by the Android KitKat which includes a AOT Java Compiler (developer feature, disabled by default).
* C / nginx is a compiled language/platform that you can use to build websites.

Ajouter un commentaire

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • Pour publier des morceaux de code, entourez-les avec les balises <code>...</code>. Pour du PHP, utilisez. <?php ... ?>, ce qui va colorier le code en fonction de sa syntaxe.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Les lignes et les paragraphes vont à la ligne automatiquement.
By submitting this form, you accept the Mollom privacy policy.