That's quite a performance improvement. I'm curious if this was directly related to just switching to PHP7, or something under the Tumblr hood, that they improved upon as well. While reviewing their own code.
I guessing that it was just the PHP7 switch. We are seeing similar performance/resource-usage changes just with a switch from PHP5.6 (opcache enabled) to PHP7 (opcache enabled).
It sounded like they were running the same code in both places, not a separate code base. (With the exception of extensions.) So unless those extensions are heavier than I'd guess, probably just the PHP upgrade.
PHP 7 contains a massive overhaul of the PHP interpreter's internal data structures (phpng), which drastically cuts memory usage and improves cache locality, which leads to better performance. There's also some new optimisations, too.
I wasn't involved in the switch, but having extensive knowledge of the code base at Tumblr (used to work there for 3 years) as well as extensive knowledge of PHP (have been a PHP contributor for ~13 years), I can say that this was likely >95% directly related to the switch to PHP7. Many of the patterns used in Chorus (inhouse framework Tumblr is based on) and in the codebase in general would very much benefit from the changes in PHP7 internals.
Another piece to this (for those using MySQL as their backend) is that updates to MySQL can improve things quite significantly as well.
In my work environment I"m the main MySQL user so I had setup a dedicated MySQL 5.5 server a few years ago that I hadn't upgraded to any newer versions since then (hey it wasn't broke right?). But recently I had been looking into upgrading just because it felt like it was time, but earlier this week I was checking out some performance degradation on one of our sites and noticed in my local copy it was actually running quite a bit faster.
Investigating further, it seems that in the newer versions of MySQL (in my case, my local XAMPP was running MariaDB 10.1.x) the performance has improved quite a bit, particularly for the types of queries I was running on this site (which used a number of subqueries and GROUP BY clauses).
Without any sort of application level caching making this single switch from MySQL 5.5 to MariaDB 10.1.19 improved load times from about 3.0 seconds to 1.0 seconds and I'm going to add some application level caching as well to improve things further.
This was all without switching PHP versions on this particular site (which is still using PHP 5.4.45)...just thought I'd share since sometimes the slowness isn't always improved as much just by upgrading PHP (which is something I'd like to do too for this site, but at the moment the framework I'm using on the site isn't ready for PHP 7 so it'd be quite a bit of work to switch it out).
Complete list of new features in MySQL 5.7 [0] (in bullet form) would show scores of performance improvements. The performance improvements from 5.5 to 5.6 were significant and 5.7 is much much better.
It's important to distinguish between cases where it is slower, and cases where query plans change.
MySQL 5.7 changed the cost-model significantly, so while it will be better on most queries, there are cases where two-wrongs-made-a-right; and edge case queries may be slower. To mitigate this (as it was somewhat expected), MySQL 5.7 also introduced new query hints and server-side query rewrite.
(In the case of the link you provided, OP responded later saying 5.7.10 improved performance again.)
In addition to latency and cpu usage improvements, we also saw a substantial drop in memory usage for code that allocated a large number of objects. After the initial migration, PHP7 has been very solid in production.
We use the Rackspace Cloud Sites PAAS. They recently released a PHP 7 beta.
For our sites running Bolt - a PHP CMS which makes heavy use of autoloaded classes - we saw a performance improvement between 45 and 55 percent. For Wordpress, it was around 30-40%.
It's possible that when switching to PHP7 opcache was enabled by default, whereas it may not have been beforehand. Most likely opcache is responsible for the autoloading improvement.
That said, a faster parser and intepreter would do autoloading faster as well, so it may not be opcache at all and just by virtue that the autoloaded classes are interpreted faster.
How are you finding bolt? I was looking into it for a personal project and the requirements that composer introduced for auto installing addons made life complicated.
Though I guess that is really a composer issue, the inability to not use something like curl when allow_url_fopen wasn't available seems insane to me. allow_url_fopen is not a great thing to have enabled in production.
I've found bolt to be completely awesome. I've made 5 or 6 sites with it, made a couple utility extensions, and used the local extension system to do stuff like custom search, a basic shopping cart, and a custom data export feature. Aside from the technology stuff it's got a positive community, good documentation, and active user base on the forum and chat.
Despite all the negativity about PHP, I sincerely thank all the team behind it. Thanks to PHP and its easy way of start building stuff, I started learning programming.
While I have moved on, not because it's hip to do so, I hope the community keeps rocking. Thank you again and congratulations.
Is there anymore major performance improvements left to make to PHP or is everything else just dimishing returns?
No disrespect to the huge amount of work the PHP team has already completed, they should be praised.
Just curious to know if we can expect anymore major performance improvements like we saw from v5 to v7.
EDIT: After further searching, appears PHP 8 will have some sort of JIT (with the hope that it'll continue to bring significant perf improvements. More info at http://news.php.net/php.internals/95531
I'm also confused. Php 7 has Opcache, which according to the documentation:
"OPcache improves PHP performance by storing precompiled script bytecode in shared memory, thereby removing the need for PHP to load and parse scripts on each request."
Our perf work in the 7.1 cycle hasn't shown any significant gains on real applications (we have some improvements for computationally intensive code -- like arithmetic inside tight loops).
Whether or not the JIT will bring a major improvement for applications is not yet clear, but the hope is obviously there.
Right, having done this myself long ago, much of the performance improvement comes from just raw C-code in the runtime. Making less string copies, etc. are a big deal, especially on real programs. That's much of what you've seen in the first set of PHP 7 improvements.
Taking PHP from a bytecode interpreter to generated x86 will mean that in places where you don't end up "hopping out", you should see closer to C-code like performance (the same is true for JavaScript, Python, etc.). Unlike a few years ago though, PHP7's scalar type hints and other slight tweaks (made on purpose!) should make this an even easier task than it was for say PHP 5.4. Type inference is incredibly effective, and in practice (see Paul Biggar's excellent thesis on this) there really isn't that much polymorphism in PHP programs. Parameters to functions usually have one maybe two types or they're actually polymorphic and see 15+ variations. This is just the nature of what you're able to reason about ("Can I really handle this being an int, float, bool, string, array, function callback, or arbitrary class here? Of course not...").
That said, once you get the two of them working really well together (eliminating friction at calling from the generated machine code for the language back into the runtime), you see additional benefits even on real programs. It's too bad they only report what the API endpoint did, that's relatively easy! (The full dashboard load was much more complex, with tons of crazy class loading and JSON serialization/deserialization, lots of Thrift RPCs, and plenty of memcache).
Source: I've run the Tumblr dashboard in production briefly on a system with a JIT-based runtime ;)
Try `print false;` and see if you get the result you expect[0]. Because it differs compared to node, perl, python(Yes Yes first char uppercase) and other languages I can not think of.
Also good luck with the param ordering of `array_map` compared to `array_filter` and `array_reduce`. Actually get use to the word array. Because in 2009 the PHP developers did not think array is a important data type that needs a short hand array() vs [], and all their function names `array_` shows this ugliness.
I would advice rather spend your time learning python or javascript. But I acknowledge PHP became a de facto standard with MediaWiki, WordPress, Facebook, dragging the broken language into the 21st century.
We at www.pricecheck.co.za switched early this year. We were supersized how easy the transition was. We definitely saw a decrease in cpu usage about 20%. Also most of our php-extension(nothing exotic) was also supported already...
Unrelated question: I couldn't find any HN discussions on, what's Tumblr's future since the Verizon purchase? Yahoo let it be, it seems, has Verizon mentioned it?
I wonder if Wikipedia regrets its switch to HHVM, having in mind that PHP7 is quite the same fast as HHVM is real apps and switching to it would require much less work than to HHVM.
52 comments
[ 3.4 ms ] story [ 95.0 ms ] threadhttps://www.symfony.fi/entry/symfony-benchmarks-php-56-hhvm-...
http://www.zend.com/en/resources/php7_infographic
https://techblog.badoo.com/blog/2016/03/14/how-badoo-saved-o...
Edit: A slide deck with some detail on why it's so much better: http://www.slideshare.net/nikita_ppv/php-7-what-changed-inte...
Another one, Taking PHP Seriously [1].
[0] https://news.ycombinator.com/item?id=12704511
[1] https://news.ycombinator.com/item?id=12703751
In my work environment I"m the main MySQL user so I had setup a dedicated MySQL 5.5 server a few years ago that I hadn't upgraded to any newer versions since then (hey it wasn't broke right?). But recently I had been looking into upgrading just because it felt like it was time, but earlier this week I was checking out some performance degradation on one of our sites and noticed in my local copy it was actually running quite a bit faster.
Investigating further, it seems that in the newer versions of MySQL (in my case, my local XAMPP was running MariaDB 10.1.x) the performance has improved quite a bit, particularly for the types of queries I was running on this site (which used a number of subqueries and GROUP BY clauses).
Without any sort of application level caching making this single switch from MySQL 5.5 to MariaDB 10.1.19 improved load times from about 3.0 seconds to 1.0 seconds and I'm going to add some application level caching as well to improve things further.
This was all without switching PHP versions on this particular site (which is still using PHP 5.4.45)...just thought I'd share since sometimes the slowness isn't always improved as much just by upgrading PHP (which is something I'd like to do too for this site, but at the moment the framework I'm using on the site isn't ready for PHP 7 so it'd be quite a bit of work to switch it out).
[0] http://www.thecompletelistoffeatures.com/
[0]: https://m.reddit.com/r/zabbix/comments/3txgov/poor_performan...
MySQL 5.7 changed the cost-model significantly, so while it will be better on most queries, there are cases where two-wrongs-made-a-right; and edge case queries may be slower. To mitigate this (as it was somewhat expected), MySQL 5.7 also introduced new query hints and server-side query rewrite.
(In the case of the link you provided, OP responded later saying 5.7.10 improved performance again.)
(I am the Product Manager for the MySQL Server, but yes - I personally own the domain.)
https://www.mysql.com/why-mysql/benchmarks/
If you already have a well configured server you tend to see smaller performance improvements between versions.
For our sites running Bolt - a PHP CMS which makes heavy use of autoloaded classes - we saw a performance improvement between 45 and 55 percent. For Wordpress, it was around 30-40%.
That said, a faster parser and intepreter would do autoloading faster as well, so it may not be opcache at all and just by virtue that the autoloaded classes are interpreted faster.
Though I guess that is really a composer issue, the inability to not use something like curl when allow_url_fopen wasn't available seems insane to me. allow_url_fopen is not a great thing to have enabled in production.
While I have moved on, not because it's hip to do so, I hope the community keeps rocking. Thank you again and congratulations.
No disrespect to the huge amount of work the PHP team has already completed, they should be praised.
Just curious to know if we can expect anymore major performance improvements like we saw from v5 to v7.
EDIT: After further searching, appears PHP 8 will have some sort of JIT (with the hope that it'll continue to bring significant perf improvements. More info at http://news.php.net/php.internals/95531
Are you then suggesting that PHP 8 (with a JIT) will be significantly faster than HHVM?
It may mean that a lot of HHVM's performance improvements were not related to JIT.
"OPcache improves PHP performance by storing precompiled script bytecode in shared memory, thereby removing the need for PHP to load and parse scripts on each request."
How would JIT features come into play with it?
Whether or not the JIT will bring a major improvement for applications is not yet clear, but the hope is obviously there.
Taking PHP from a bytecode interpreter to generated x86 will mean that in places where you don't end up "hopping out", you should see closer to C-code like performance (the same is true for JavaScript, Python, etc.). Unlike a few years ago though, PHP7's scalar type hints and other slight tweaks (made on purpose!) should make this an even easier task than it was for say PHP 5.4. Type inference is incredibly effective, and in practice (see Paul Biggar's excellent thesis on this) there really isn't that much polymorphism in PHP programs. Parameters to functions usually have one maybe two types or they're actually polymorphic and see 15+ variations. This is just the nature of what you're able to reason about ("Can I really handle this being an int, float, bool, string, array, function callback, or arbitrary class here? Of course not...").
That said, once you get the two of them working really well together (eliminating friction at calling from the generated machine code for the language back into the runtime), you see additional benefits even on real programs. It's too bad they only report what the API endpoint did, that's relatively easy! (The full dashboard load was much more complex, with tons of crazy class loading and JSON serialization/deserialization, lots of Thrift RPCs, and plenty of memcache).
Source: I've run the Tumblr dashboard in production briefly on a system with a JIT-based runtime ;)
the graph they're referencing shows the peak at higher than the previously lowest load. i guess "peak average" is the key to this.
https://wiki.php.net/rfc/php6#historical_context
http://php.net/manual/en/migration70.incompatible.php
Also good luck with the param ordering of `array_map` compared to `array_filter` and `array_reduce`. Actually get use to the word array. Because in 2009 the PHP developers did not think array is a important data type that needs a short hand array() vs [], and all their function names `array_` shows this ugliness.
I would advice rather spend your time learning python or javascript. But I acknowledge PHP became a de facto standard with MediaWiki, WordPress, Facebook, dragging the broken language into the 21st century.
[0]: http://pastebin.com/raw/P6BTmceL
I would really like to talk about this constructively.
[petty]: https://gist.github.com/Morabaraba/3e93d7d21e16b6eb8266ee1cc...
ps. can you not edit your comment anymore... could you ever edit your comment?
The only frustrating thing about it is, that there was so much potential unused for so long. Manh k/mwatts of power for nothing.