HHVM Demonstrated to be 18.7% Faster Than PHP 7 on a WordPress Workload

hhvmhack

This week HHVM developers shared the results of their first ever open source performance lockdown. HHVM is Facebook’s open source PHP execution engine, originally created to help make its infrastructure more efficient. WordPress managed hosts, including WP Engine, Pagely, and SiteGround, have added HHVM hosting options within the last year to cater to customers who require better PHP performance.

During the HHVM team’s two week lockdown, developers focused on optimizing builtin functions, dynamic properties, string concatenation, and the file cache. The goal was to maximize requests per second (RPS) with WordPress, Drupal 7, and MediaWiki, using their oss-performance benchmarking tool.

“During lockdown we achieved a 19.4% RPS improvement for MediaWiki workloads, and a 1.8% RPS improvement for WordPress,” Facebook developer Paul Bissonnette reported. “We demonstrated that HHVM is 55.5% faster than PHP 7 on a MediaWiki workload, 18.7% faster on a WordPress workload, and 10.2% faster on a Drupal 7 workload.”

These results were based on configuring each framework with a sample dataset designed to approximate an average installation. In order to create the WordPress workload, the HHVM team used URLs from the hhvm.com access logs to extract data.

The report contains a walkthrough of how the benchmarking tool works to approximate the maximum possible RPS of a server under a high load. Some of the most notable performance differences were summarized in the results of the engine comparison chart, which demonstrates the difference between PHP 5, PHP 7, and HHVM.

engine-comparison

During the lockdown, the team also experimented with introducing asynchronous query execution to WordPress, the results of which the team plans to write about in the near future.

As an exercise, we evaluated the benefits of async MySQL in the WordPress environment. By modifying portions of WordPress to take advantage of the async capabilities offered by Hack and HHVM, we were able to examine the potential for performance gains through async execution. In our test environment we separated the MySQL and PHP hosting to separate machines within the same datacenter to approximate a realistic WordPress stack. The introduction of asynchronous query execution can demonstrate performance gains in both RPS and response time.

It will be interesting to see a more detailed report of the benefits they found from introducing async capabilities to WordPress. Overall, the lockdown provided an opportunity for collaboration across open source projects, resulting in a host of optimizations that will help OS frameworks perform better with HHVM in the future. The HHVM team plans to ship these improvements with the next release.

19

19 responses to “HHVM Demonstrated to be 18.7% Faster Than PHP 7 on a WordPress Workload”

  1. Interesting. I suspect that many people will take this away: PHP 7 is 3x quicker than PHP 5 for WP, and HHVM is 3.5 faster. So, PHP 7 will get you 80%+ of the speed increase that HHVM will get you – but probably without as much disruption, and fewer unknown factors.

  2. The HHVM discussion in the context of wordpress is mostly irrelevant to 99% of wordpress sites. The reason for the existence of HHVM is to facilitate a fast code updates to a very large amount of servers. The comparison against the performance of PHP is nice but the real competition (at least internally in FB) of HHVM is against compiling the PHP code into simple executable.
    So it will benefit thing like wordpress.com, maybe even wordpress.org, but for most site it will not show any improvment whatever.

    keep in mind that the biggest bottle-neck in wordpress is reading from the DB and HHVM do not help with that, so you will still need a caching plugin which will give you a 100x performance boost so why bother at all with the HHVM 3.5x boost that you will enjoy only once an hour when the cached version of the page is generated.

    FB are in a relatively unique position as most of their traffic is by logged in users therefor they have very limited ability to do aggressive caching. This is probably not true for even wordpress.com.

    • Plenty of sites (Membership, eCommerce, forums, etc) rely on a large percentage of dynamic page views. Throw a large multisite in the mix and PHP is a huge bottleneck. WP is not just blogs anymore!

      • ecommerce should be cached until there is a sale. Even amazone is partially cached.
        As for community sites, it depends on the exact nature of them but most of them obey the rule of 10% contributors and 90% lurkers. For the 10% participants it is more important to install object cache otherwise you will not notice any improvment from HHVM because most of the time will be used on the slowness of DB access

        I have never heard of a wordpress site in which php was a bottle neck. In all real life cases it was always the memory and not the CPU power which the site ran out of. With memory usage of 100M per request to support 20 RPS for which you will need more then 2G free memory to handle so many requests at the same time, and 2G memory servers are not entry level servers and usually have more CPU power as well. But this is my experience and I would gladly learn about some case in which CPU did matter for wordpress site.

        • The faster the request is done – the more rpm you get, pages load faster. We’re not talking about CPU load but about the time it takes to serve the request. And it matters for everyone. Even if you have low load, test your site with tools.pingdom.com or similar tool and see how much time you are waiting for the response from server – usually it’s 300-800ms. With HHVM it’s 80-140ms. On EACH request which loads WP and PHP. I’m not talking about a full page cache served by Nginx from RAM because the FPC should really be your last resort. If you’re running a site which needs users to be logged in – you can’t use FPC. In this case Nginx + HHVM + Redis + MariaDB is a perfect combo to make your site lightning fast and save you some money on servers.

    • On the highly dynamic and optimized large WP site I manage 60% of transaction time is in PHP (100ms), only 40% is in db (SSD RAID) and Memcached. That’s latest PHP 5.5 with highly tuned OPcache. Looking forward to cutting almost 50% of our page gen time with PHP7!

  3. I’m in the process of converting this 1.7+ million page HTML site to WordPress. I first pulled everything into a Laravel 4 framework simply because I know the framework much better than WordPress. Then I set out to build a custom plugin in WordPress that basically is a tool to manage 1.7 million articles and WordPress out of the box features for managing so many articles is impossible.

    Q: Does anyone have advice on how you would manage a million articles? Sorting through the list of articles for example from either an Admin or End-user becomes tedious and daunting and slow depending on how the data is retrieved.

    • I don’t think there is a “correct” answer to your question, as it depends on what your requirements are and which specific problems you are experiencing. I can imagine some situations in which a custom interface for handling the editing of pages would be necessary.

  4. I’m with Dave on this one. Performance is great, but compatibility is better. I’ll be sticking with PHP for now.

    Don’t get me wrong, the work that Facebook is doing here is important and has certainly helped spur the PHP core devs into improving it’s performance and feature set, so it’s all good stuff and well worth doing.

  5. People really use HHVM? It’s crap software that rarely works, even if by some miracle it gets compiled. It’s unstable, lacks features, it’s poorly documented and I won’t even start what a nightmare it is to create extensions for it. PHP7 is near its performance, but it comes with all the stability and with a bunch of smart people working on it, unlike Facebook people who are at best mediocre engineers. Anyone running serious website that makes them money would never even think of installing HHVM. Also, benchmarks are ran on the same machine where the http server is which is dumb beyond any reason. I would rather run PHP 4 than HHVM, it’s a piece of shit and will always remain, like most Facebook’s products.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.