The Definitive PHP 7.0 & HHVM Benchmark

Updated on June 05, 2017

It’s a great day for all of us who use PHP every day and that doesn’t just include developers (and web hosting companies) but end users as well. It will speed up the most popular web development language in the coming weeks and months which means faster websites and web services for everyone!

We’re addicted to optimizing the load times of websites and we’ve released numerous guides on the topic previously, take a look at A Beginner’s Guide to Website Speed Optimization, Best Free Website Performance Testing Tools, and more.

To see how much of an improvement we can expect from this new PHP interpreter we put the public release version of PHP 7.0 to test and compared a couple of popular software suites’ performance using PHP 5.6.16, PHP 7.0 and HHVM 3.10.1 on a bare metal server (so virtualization doesn’t interfere with the results). Tested software includes WordPress 4.3.1, Drupal 8, Magento 2.0 CE, OctoberCMS build 309, PyroCMS v3 beta2, and Flarum v0.1.0-beta.4.

Long story short, HHVM wins hands down.

The bare metal machine we used for the following benchmarks has an Intel Xeon E5-2630v3 processor (8 CPU cores and 16 threads), 64 GB RAM and 2 x 4 TB SAS 7200 rpm HGST disks in RAID 0.
We used MariaDB 10.1.9 for the MySQL server and Nginx 1.9.7 for the web server.

WordPress 4.4

Updated article on December 9, 2015, after WP4.4 was released. We used dummy content from wptest.io and benchmarked the home page for a minute with 15 concurrent users. WordPress’s was the only test where we could use HHVM’s Repo Authoritative mode without having to make time consuming modifications to the software in question. It adds some extra speed but it may not be something everyone can take advantage of because of the extra deployment steps required to make it work.

WordPress 4.4 PHP7 HHVM Benchmarks

WordPress 4.4 HHVM RepoAuthoritative benchmark result: 358.33 trans/sec
WordPress 4.4 HHVM benchmark result: 335.13 trans/sec
WordPress 4.4 PHP 7.0 benchmark result: 287.92 trans/sec
WordPress 4.4 PHP 7.0 without opcache benchmark result: 84.87 trans/sec

WordPress 4.3.1

We used dummy content from wptest.io and benchmarked the home page for a minute with 15 concurrent users.

WordPress 4.3.1 PHP Benchmarks

WordPress 4.3.1 HHVM RepoAuthoritative benchmark result: 375.48 trans/sec
WordPress 4.3.1 HHVM benchmark result: 357.69 trans/sec
WordPress 4.3.1 PHP 7.0 benchmark result: 306.24 trans/sec
WordPress 4.3.1 PHP 5.6.16 benchmark result: 106.45 trans/sec

Drupal 8.0.1

Standard installation with the devel module’s 50 posts sample data. Benchmarked the home page for a minute with 15 concurrent users. This was the most interesting result of all, we deleted the Drupal installation completely after getting these results and installed again, set it up same as before and re-did all the test. Almost exactly the same results!

Drupal 8 PHP Benchmarks

 

Drupal 8 HHVM benchmark result: 1739.28 trans/sec
Drupal 8 PHP 7.0 benchmark result: 917.10 trans/sec
Drupal 8 PHP 5.6.16 benchmark result: 794.20 trans/sec

Magento 2.0 Community Edition

Standard install with the official sample data package. Magento’s internal caches were turned on otherwise it’s a miserable 5 transactions/second… Benchmarked the home page for a minute with 15 concurrent users.

Magento 2.0 PHP Benchmarks

Magento HHVM benchmark result: 192.19 trans/sec
Magento PHP 7.0 benchmark result: 183.87 trans/sec
Magento PHP 5.6.16 benchmark result: 113.34 trans/sec

OctoberCMS

A Laravel based CMS system that’s popular in itself plus gave us the opportunity to test the underlying Laravel framework as well! We chose the Vanilla theme during installation which has a user system, a blog and a forum. Benchmarked the home page for a minute with 15 concurrent users.

OctoberCMS

OctoberCMS HHVM benchmark result: 583.07 trans/sec
OctoberCMS PHP 7.0 benchmark result: 407.89 trans/sec
OctoberCMS PHP 5.6.16 benchmark result: 248.19 trans/sec

PyroCMS v3 beta2

Another Laravel based content management system. We used the default setup and added a blog post and tested that “single page” for a minute with 15 concurrent users.

PyroCMS 3

PyroCMS HHVM benchmark result: 177.39 trans/sec
PyroCMS PHP 7.0 benchmark result: 145.95 trans/sec
PyroCMS PHP 5.6.16 benchmark result: 75.17 trans/sec

Laravel 5.1.11

We installed the default Laravel package and tested its “welcome screen” without any database connections. Don’t forget that OctoberCMS above is built on Laravel as well so it looks like as soon as you add some other stuff to the tests as well HHVM takes back the lead. We’ve run the tests for a minute with 10 concurrent users. When we used php artisan optimize –force and php artisan config:cache results were 1.5x better than the ones below.

Laravel 5.1 PHP7 Benchmark

Laravel 5.1.11 HHVM benchmark result: 1128.41 trans/sec
Laravel 5.1.11 PHP 7.0 benchmark result: 1363.24 trans/sec
Laravel 5.1.11 PHP 7.0 without opcache benchmark result: 245.60 trans/sec

Flarum v0.1.0-beta.4

Delightfully simple forum software. Flarum is the combined successor of esoTalk and FluxBB. It uses a mix of Laravel’s, the Zend Frameworks and Symfony components (among others of course) and it’s an up and coming software suite in the PHP world so we thought it’d be interesting to include it.

Oops: for now it looks like we’ll have to keep Flarum here as a placeholder only as it doesn’t run either with HHVM or PHP 7. On HHVM we got “Fatal error: Return inside a finally block is not supported in vendor/flarum/core/src/Foundation/Application.php on line 120” and on PHP 7 it was “Notice: Undefined property: stdClass::$data in vendor/flarum/core/src/Http/Controller/ClientView.php on line 326” and a 90% broken screen completed with JavaScript errors… We’ll talk to the devs about these issues and update this post once it’s stable on these new platforms!

Summary

That’s all, folks! The results are pretty self-explanatory. If you want us to include another framework or app, let us know! Comments are welcome.

A quick note: if you use Debian/Ubuntu chances are you’re using Ondřej Surý‘s PHP packages. He maintains his repositories in his free time and accepts donations. If you feel like he’s helped you in the past, buy him a beer! His bitcoin address is 15WRQCrVHWUdcn3sbT7PF6u2FJGfbb8GW5

Featured image via Digital Ocean.

This article was written by Mark Gavalda

Mark has many years of experience leading teams in the fields of marketing, web design and development. As a dev guy he used his WP expertise to collect the know-hows of creating a reliable and customer friendly hosting company to satisfy the increasing demand of clients. He is an urban cyclist and autodidact who never stops learning new skills.

Hand-picked related articles

  1. Gravatar for this comment's author
    Marco Pivetta December 8, 2015 at 8:47 pm

    The transactions/second on the Drupal 8 benchmark result seem to be inconsistently reported between the graph and the numbers right below: I think the HHVM result should be the one stating 1739.28 transactions/second (if the graph is authoritative)

    1. Gravatar for this comment's author
      Mark Gavalda December 8, 2015 at 9:09 pm

      That was a typo indeed, thanks for letting us know! We fixed it.

  2. Gravatar for this comment's author
    hollodotme December 8, 2015 at 10:35 pm

    I’m sorry, but IMHO all these tested apps weren’t “frameworks”, these are CMS applications.
    Most of them with a bunch of “legacy code” written far before php7 was released.

    At least I expected Zend Framework or Symfony in a “Definitive PHP 7.0 & HHVM Benchmark” with “most popular frameworks”. And I’m not a fan of both of them. :)

    So the only conclusion I can see here is, HHVM runs non-php7 code faster than php7.

    I think the goal of the php7+ movement is to write (new) code using all the advantages and improvements php7 came up with.

    1. Gravatar for this comment's author
      Mark Gavalda December 9, 2015 at 8:58 am

      You cannot test just the frameworks, really. You have to have an application that’s build on those frameworks and if you take a closer look OctoberCMS and PyroCMS were included for this reason, they build upon Laravel, Symfony and some other very up to date PHP libraries.
      Still, if you have an exact recommendation of what to test, please let us know.

      1. Gravatar for this comment's author
        Slava UA December 9, 2015 at 9:34 am

        Frameworks are not WordPress, Drupal, Flarum, etc. That’s like testing PHP speed using WordPress! You are testing bloated WordPress, Drupal etc speed. Frameworks are Yii2, Symphony, Laravel etc – and you know that.
        So just install them, they all have some kind of demo pages (in Yii2 Advanced that is login/logout system plus several extra pages) and test that.

        Your post will be ok only if you edit the “We tested the most popular PHP based frameworks” to “We tested the most popular PHP based software applications” or similar.

        1. Gravatar for this comment's author
          Mark Gavalda December 9, 2015 at 10:31 am

          Ah okay I get it, it was a wrong choice of words in the introduction, thanks for pointing that out. I can do even better than “just fixing” that: add tests for the demo pages of the frameworks that have some!

          1. Gravatar for this comment's author
            Slava UA December 9, 2015 at 10:32 am

            Thanks!

          2. Gravatar for this comment's author
            Johnny December 10, 2015 at 9:29 am

            Would be awesome too see some Yii / Yii2 benchmarks as well ! Thank you !

          3. Gravatar for this comment's author
            Mark Gavalda December 10, 2015 at 9:54 am

            Latest Laravel added! Will add more.

          4. Gravatar for this comment's author
            Andrej Pinčík December 11, 2015 at 8:26 pm

            Could you try Nette 2.3.8 (already support PHP 7) :) Thanks much

          5. Gravatar for this comment's author
            Terrence Campbell December 13, 2015 at 2:41 pm

            I’m developing a social network for League of Legends using Symfony 2.8. Switching from HHVM to PHP 7, even Guzzle itself performs much faster. Eventually when my site is really active, we’ll know who’s tougher.

    2. Gravatar for this comment's author
      Cam Spiers December 10, 2015 at 6:14 am

      Some fair points but they equally apply to HHVM considering that HHVM now supports PHP7 features too (plus a whole lot more).

    3. Gravatar for this comment's author
      kabatza January 15, 2016 at 4:55 pm

      I don’t believe everything I read, so I did run my own tests and I had very similar results. I can tell you even PHP5 is almost twice as fast compared to HHVM when used for 3-4 file based php scripts, and this is all I need to use.

      It may look impressive how Drupal can get 1739 t/s, in this test but I’m not sure if it is using any type of cache by default, and it took some powerful hardware to do it as well.
      I have some custom coded applications running on a 512MB single core VPS with Nginx+PHP5 (all default settings) and I get almost 2000 t/s out of it, with 60 concurrent users without any errors or timeouts. If I cache the pages, then php is not used at all and I get over 4000 t/s.

      When I try the same code and VPS with Nginx+HHVM, I cannot get more than 1000 t/s. So it is twice the result for the same money….. $5 in this case LOL! Of course with the cache enabled it goes back to 4000+ as again HHVM is not used.

      PHP7 is fast, and for me the only easy way to go faster at the moment is using NodeJS or google’s Go! Tje latest Go version is faster than C/C++ but fairly easy to use for the web…which is very cool.

    4. Gravatar for this comment's author
      Venimus February 17, 2016 at 1:39 am

      IMHO the tests are good. It shows that you can just migrate PHP without touching (most of) the code to gain significant performance boost.

    5. Gravatar for this comment's author
      LY January 10, 2017 at 5:44 pm

      AGREED!

      Plus thats php 7.0. The newer 7.1+ release has ironed optimzation and delivers blasting speed. I roll it with yii2 and it flys

  3. Gravatar for this comment's author
    Paul Yakubets December 8, 2015 at 11:09 pm

    Thanks for your article and what about latest Laravel?

    1. Gravatar for this comment's author
      appleboy48 December 9, 2015 at 1:21 am

      Agree

    2. Gravatar for this comment's author
      Mark Gavalda December 10, 2015 at 9:54 am

      Latest Laravel added!

  4. Gravatar for this comment's author
    Kay Leung December 9, 2015 at 7:38 am

    with OPCache enabled?

    1. Gravatar for this comment's author
      Mark Gavalda December 9, 2015 at 8:55 am

      Definitely. Without opcache it’s about half of these numbers.

      1. Gravatar for this comment's author
        Kay Leung December 9, 2015 at 9:40 am

        Thanks! Your Drupal 8 benchmark result matched http://kazanir.github.io/profiling/. There’s huge performance increase between with / without HHVM Repo. Auth. I wonder if “opcache.file_cache” will help. (It’s disabled by default)

  5. Gravatar for this comment's author
    Zach December 9, 2015 at 5:33 pm

    How do enable / disable opcache in PHP7? I’m testing it out on one of my servers. Thanks for the insightful article.

  6. Gravatar for this comment's author
    Sarah Yui Tsumagoi December 9, 2015 at 9:09 pm

    If I’m not mistaken Flarum was built on Lavavel & Ember.js (Then moved away from Ember.js to Mithril, which is a client-side MVC framework.), you should read up on the past posts by Toby.
    http://tobyzerner.com/mithril/

  7. Gravatar for this comment's author
    Gor Martsen December 9, 2015 at 11:02 pm

    Thank you for great review!

    I can recommend to add Backdrop CMS.
    It is going to support PHP7 from 1.2.3 release.
    Right now you need to install it from
    https://github.com/backdrop/backdrop/tree/1.2.x

    It is dev version that contain php7 ready patches.

  8. Gravatar for this comment's author
    Hugo December 12, 2015 at 9:37 am

    How about the Banshee Content Management Framework? http://www.banshee-php.org/ It’s not a very known framework, but it’s a modern and fast one. I really like to see it tested.

    1. Gravatar for this comment's author
      Proyb P December 12, 2015 at 3:46 pm

      Looking at this years ago and decided not to try, when it hit any vulnerabilities or scaling issues, you would rather go with Nodejs with a ready guide on secure tips and allows you to develop with Bliss.js and other components libraries, you are good to go.

      For this reason, I have decided to stop developing with Laravel after using them for 2 years.

      1. Gravatar for this comment's author
        Hugo December 13, 2015 at 9:46 am

        Security issue? Scaling issue? Banshee has never had any security issue. It’s more secure than any other framework or CMS. And what scaling issue are you talking about?

  9. Gravatar for this comment's author
    Mark Kaplun December 12, 2015 at 10:15 am

    as others already said, this is not a test of PHP vs HHVM it is a test of (HHVM+DB) vs (apache+php+DB) and it would have been extremely surprising if the results would have been any different since HHVM is optimized to run PHP cutting out the middleman and probably other useless features of apache.

    There was never a question if HHVM is faster, the question was always does the difference is big enough for people to abandon the flexibility of other web servers for it.

    1. Gravatar for this comment's author
      Theodore R. Smith December 12, 2015 at 10:23 am

      Apache was not used in any of the tests. Great reading comprehension!!

      1. Gravatar for this comment's author
        Mark Kaplun December 12, 2015 at 12:14 pm

        Not sure who is the bigger idiot the one that doesn’t notice that nginx was used and not apache or the one that comment on the least important part of my comment

        1. Gravatar for this comment's author
          Theodore R. Smith December 12, 2015 at 1:17 pm

          Let me be specific: First, no where did I call you an idiot. Second, I apologize for being snarky :-/ Third, the tests used FastCGI and nginx, so web server speed wasn’t part of the tests, for the most part. And, benchmarks that DO NOT include real-world SQL queries are NOT very good, in my honest opinion, merely theoretical conjecture.

          1. Gravatar for this comment's author
            tomzur December 12, 2015 at 7:39 pm

            Hi Theodore, the next article will be about the web server’s speed, 6 provider! Stay tuned! Cheers, Tom

          2. Gravatar for this comment's author
            Emil Cataranciuc December 13, 2015 at 5:55 am

            I am sorry but I think that once you include a component in a setup you test its speed also. At least a combination of the components.

          3. Gravatar for this comment's author
            Mark Kaplun December 13, 2015 at 6:10 am

            Maybe I should have stated my comment better, but looking again into the graph I see that for laravel PHP7 is faster and that is a test with no DB, so are you really comparing the speed of the interpreter or the quality of the DB driver it uses? Is HHVM have an integrated driver which allows it to skip the dynamic loading of functions that PHP has to do and that explains the difference?

  10. Gravatar for this comment's author
    NextLocal December 12, 2015 at 7:20 pm

    Thanks for posting this, just curious. Do you deploy RepoAuthoritative on all of the sites you host, and do you have benchmarks available without RepoAuthoritative?

  11. Gravatar for this comment's author
    Emil Cataranciuc December 13, 2015 at 5:43 am

    It may be you forgot to enable caching in Drupal.

    1. Gravatar for this comment's author
      Emil Cataranciuc December 13, 2015 at 5:46 am

      Also you didn’t post any reports on memory and CPU usage. And how did you setup the server? For an IT company the article is poorly written.

      1. Gravatar for this comment's author
        Thomas Svenson December 17, 2015 at 4:23 pm

        Caching is actually on by default in Drupal 8, see http://wimleers.com/article/drupal-8-dynamic-page-cache. That is most likely the reason why the performance boost isn’t as big as for the others.

        1. Gravatar for this comment's author
          Emil Cataranciuc December 17, 2015 at 5:02 pm

          Strange thing, on my last install it was off.

  12. Gravatar for this comment's author
    Thomas Svenson December 17, 2015 at 4:29 pm

    @MarkGavalda:disqus: Standard installation for Drupal 8 has cache on as default, see http://wimleers.com/article/drupal-8-dynamic-page-cache for more information. If you did not turn that off, then it is probably a reason to why the PHP 7 boost isn’t bigger.

    Would be interesting to see the result comparing the benchmark with/without caching enabled in Drupal 8. Should potentially reveal something interesting.

    1. Gravatar for this comment's author
      Jeff Geerling December 23, 2015 at 11:22 pm

      I had the same concern, so I spent a bit of time today reproducing the benchmark for Drupal and here are my results: http://www.midwesternmac.com/blogs/jeff-geerling/benchmarking-drupal-8-php-7-vs-hhvm — in this case, PHP 7 is actually faster than HHVM for both cached and uncached responses!

      1. Gravatar for this comment's author
        tomzur December 24, 2015 at 1:47 pm

        Hi Jeff,

        We used a bare metal machine to do this benchmark test. You should try your’s again using a bare metal machine to make the article/results authoritative.

      2. Gravatar for this comment's author
        kabatza January 15, 2016 at 5:21 pm

        Ha!… I was suspecting Drupal uses cache by default. No surprise PHP7 is faster on cached responses as well… because I do know HHVM is much slower on readfile() which is most likely what Drupal is using for reading the cache files by default.

  13. Gravatar for this comment's author
    Jan R December 24, 2015 at 9:08 am

    Could you share the PHP 7 php.ini configuration used?

  14. Gravatar for this comment's author
    STAMSTER December 24, 2015 at 10:01 am

    Test it with Phalcon framework. Nginx + PHP7-FPM + Phalcon :)

  15. Gravatar for this comment's author
    Sebastian Kleine December 29, 2015 at 2:15 pm

    We do use HHVM on production servers. But it’s not a one core machine. I’m just wondering what’s speaking against HHVM using that much CPU? The CPU is there. It’s not using all of it (blocking everything else). Why should the available CPU power not be used? Of course that’s a problem if you have just one machine doing everything (like database, storage and webserver). But in a bigger hosting environment that should not be a problem. A dedicated machine doing HHVM request using 90% of the available CPU sounds fine for me.

    1. Gravatar for this comment's author
      kabatza January 15, 2016 at 5:10 pm

      I think it depends on the environment (OS kernel etc etc)… I have not seen the issue myself. In any case 90% without load is definitely NOT fine!

      1. Gravatar for this comment's author
        gwap March 15, 2016 at 7:10 pm

        the issue occurs in several applications most notably phpMyAdmin, WordPress, and Drupal. In these 3 i’ve had nothing but problems, however i have 8 or 9 different Slim Framework + Redbean apps i maintain on HHVM and the companies are very pleased with the performance. I say you get what you pay for if you went cheap and used wordpress or drupal and expected a magical transformation by switching to hhvm, so shame on you for expecting free lunch. hire a programmer to develop a professional application that can scale and forever reap the benefits of having a superior website to your competition.

  16. Gravatar for this comment's author
    Sebastian Kleine December 29, 2015 at 2:25 pm

    Thanks for the test. We run a magento shop and did some tests ourselves. And we come to the same conclusion. Both HHVM and PHP7 are a lot faster than older PHP versions. But HHVM still outperforms PHP7 by a small amount.

  17. Gravatar for this comment's author
    Adir Kuhn December 30, 2015 at 3:01 am

    can you add Thelia e-commerce (http://thelia.net/)

  18. Gravatar for this comment's author
    ? Rf3 January 7, 2016 at 4:39 am

    Cant agree more. Php7 works better when there are many concurrent users.

  19. Gravatar for this comment's author
    gwenael chailleu January 21, 2016 at 9:29 am

    Hello Mark,

    Thanks for these data.

    We are using HHVM for speeding up our clients’ CMS for a while now. We are currently replaying all our benchmarks with PHP7. Our first target was our own wordpress website.

    Here are the results : http://www.nxtweb.fr/en/2016/01/05/php7-versus-hhvm-premier-round-sur-notre-site-wordpress/.

    We came up with these conclusions :

    => HHVM (in our testing context) is still faster than Zend interpreter.
    => PHP7 uses less memory
    => Looking at how php code spends its time, it is rather easy to get more than bare HHVM or PHP7 (we wrote a little wordpress-specific HHVM extension as a proof of concept)
    Here is the new frontier (if you allow me to be a little pompous ;-) : the php code itself.

    1. Gravatar for this comment's author
      Mark Gavalda January 21, 2016 at 11:34 am

      “we wrote a little wordpress-specific HHVM extension as a proof of concept” please tell me more! :) and your benchmarks look spot on, and very detailed, thanks for sharing!

      1. Gravatar for this comment's author
        gwenael chailleu January 22, 2016 at 1:18 am

        Hello Mark,

        I hope for you that your question is not pure politness for you’ll get an exhaustive answer ! ;-)

        Here is the story of this little .so (you can see its effects reading the “nxtweb” and “nxtweb + authoritative figures) : we used xhgui on a few urls of our website. We noticed that the managing of .mo files used half the memory allocated and something like 20% of the cpu time.

        And this may be the case for every pages of every non-english worpdress setup.

        We changed of few lines of the wordpress core, checked that it worked and then decided to wrap it all in a hhvm extension (as a poc). We used two different ways to do it : with the first one (using fb_intercept, something very elegant, I must admit ;-) we wasted two days trying to find out why we saw no improvement at all : the answer (we had no time to become sure of that) may be that functions like fb_replace_function and fb_intercept dramatically slow down hhvm. We’ve already had indications that it is the case with a newrelic extension we tuned a few months ago for a client of us.
        The other one (embedding in an HHVM .so all the .mo managing, not too proud of this one ;-) worked well.

        Each time we use a profiler on a PHP CMS we can see various improvements that can be applied to the PHP code.
        Improvements which cumulated benefits could be greater than the difference between HHVM and PHP7 results…But how could we deliver these improvements ? Contribution to the communities ? Writing plugins ? Writing HHVM/PHP extensions ? Writing bash scripts patching the whole CMS tree ?
        While taking into account the CMS versions+ PHP/HHVM versions…
        To take but an example : the modifications that you and us had to write to make the HHVM authoritative mode work (hunting down create_function calls) could be of some interest for a lot of people…
        We’ve got a lot of ideas and there is a lot to do, but unfortunately we have no time (I’d rather say no budget) for that…

        1. Gravatar for this comment's author
          Mark Gavalda January 25, 2016 at 4:26 pm

          Interesting, thanks for the detailed answer! Did you test the enhancement with an English version of WP? If I understood correctly you won’t be able to boost it as it doesn’t use the .mo files as translated WPs do?

          1. Gravatar for this comment's author
            gwenael chailleu January 26, 2016 at 12:40 am

            You understood correctly. Today, we are going to see if the same process (profiling + identifying the most cpu intensive processings + proposing alternatives + testing them) can be applied successfully to our wp site in its untranslated version. If you are interested in the results, we will send them to you.

          2. Gravatar for this comment's author
            gwenael chailleu February 1, 2016 at 5:42 am

            Hello Mark,

            So, we had a little time to see if something could be done for english-speaking wp sites.

            We reset to “en_US” the option “WPLANG” in our wp db.

            Then we successively modified some of the most cpu intensive functions (for our particular site : esc_html_, esc_attr_, Vc_Sort::sortByKey,..).

            Comparing “bare hhvm” with hhvm + our optimisations (both in non authoritative mode) in ‘latency’ mode we got these results :

            http://www.nxtweb.fr/en/2016/02/01/en_us_setup_results/

            With your throuhput method (15 concurrents during 1 minute on each of our 27 front end pages) we got these averages :

            All urls cumulated : 17486 reqs/mn against 11650 reqs/mn ==> + 50%

            There is still a lot to do: for instance, self (cumulated too, but this was not a surprise;-) cpu usage of apply_filter function is really heavy.

            The more time your dedicate to optimisation, the better the results, there is no real limit to this process. The ultimate phase being to write/rewrite wesites in C in whole or in part. That’s something we are already thinking about….;-) Please see http://www.melvenn.com/en/cawen/cawen-and-the-web-2/

            Now back to our wordpress benchmarks : our optimisations can be applied to non-english setup too, so we will rerun our tests and share the results in some news to come…

            At the same time, we wanted to see if our modifications could be delivered as an independant hhvm .extension. The answer was yes for the modifications of non-english speaking sites (for which we used the possibility in wordpress to overload an existing classes –see if !(class_exists… in wordpress code—) and no for the others. To apply those, the php code must be impacted (adding a call that execute the proper fb_replace) moreover to change the content of methods rather than plain functions we have to use fb_intercept which has proven again to be too slow.

            So, changing the php code is the solution. What to do with our little patches ? We are no directly interested in speeding up wordpress or any other php CMS or framework. But that’s clearly something we can do for people who care about PHP websites efficiency : communities, hosters and website owners.

  20. Gravatar for this comment's author
    Kingsley Felix January 23, 2016 at 10:52 am

    90% CPU that is bad……… my own issue with HHVM is the shutting down itself

  21. Gravatar for this comment's author
    Manuel January 26, 2016 at 10:05 am

    Hello,

    Are these benchmarks use page caching? You might take a look this benchmark:

    http://blog.litespeedtech.com/2015/09/04/php-7-vs-hhvm-benchmark-series-3-how-fast-can-wordpress-go/

    Without page caching HHVM can fly, but not with page caching using LiteSpeed.

    What do you think about LiteSpeed vs NGINX ? I think is a good combination LiteSpeed+HHVM, unfortunately is not available yet.

  22. Gravatar for this comment's author
    Davis May 2, 2016 at 10:40 pm

    Hey! I’m from the flarum Comunity and was surprised to see them listed here. :) The 5th beta now supports php 7. I’m not sure of HHVM support though.

  23. Gravatar for this comment's author
    David Yin June 12, 2016 at 3:54 am

    Great job. Could you think about to add phpBB 3.2?
    Its RC1 support php 7.

    https://download.phpbb.com/pub/release/3.2/unstable/3.2.0-RC1/

  24. Gravatar for this comment's author
    Niwat Panrit March 19, 2017 at 7:20 am

    What’s about Yii2-framework

Leave a Reply to Kay Leung Cancel reply

Use WordPress?

Join 20,000+ others who get our FREE weekly newsletter with WordPress tips on how to drive more traffic and revenue to your business!

You have Successfully Subscribed!

Send this to a friend