PHP 7 at Tumblr | Hacker News Reader

PHP 7 at Tumblr

engineering.tumblr.com

303 pointsllambda51 comments

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.

[0] http://www.thecompletelistoffeatures.com/

Thanks for sharing that link!

On the flip side there were severe performance degradations for certain types of queries. Notably Zabbix[0] was affected.

[0]: https://m.reddit.com/r/zabbix/comments/3txgov/poor_performan...

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

more reasons to hate zabbix? as if I needed them ;)

What the heck. You have that domain JUST for MySQL 5.7?! The potential!

In future I intend to expand it for MySQL 8.0.

(I am the Product Manager for the MySQL Server, but yes - I personally own the domain.)

I would expand it out to everything, this would actually be a helpful service. I hate digging through feature notes on everything.

Idea: post the domain as a story to HN and say you're just managing MySQL but that you'll consider all reasonable pull requests. See what comes in!

The additions to the geospatial feature are a plus. from 5.6 to 5.7 there is a huge jump in potential. Hopefully more coming

This page gives a good visual:

https://www.mysql.com/why-mysql/benchmarks/

It's not only functional updates in the software, but MySQL server tends to benefit from better defaults between major versions.

If you already have a well configured server you tend to see smaller performance improvements between versions.

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.

A recent post about PHP 7 deployment at DailyMotion [0].

Another one, Taking PHP Seriously [1].

[0] https://news.ycombinator.com/item?id=12704511

[1] https://news.ycombinator.com/item?id=12703751

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

Yes, the next major performance improvements will come from a JIT style machine, similar to what HHVM does.

I'm confused, so PHP 7 today does not have a JIT yet its performance is already on-par with HHVM (which has a JIT).

Are you then suggesting that PHP 8 (with a JIT) will be significantly faster than HHVM?

Not necessarily.

It may mean that a lot of HHVM's performance improvements were not related to JIT.

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

How would JIT features come into play with it?

Precompiled here means bytecode, not machine code. OPcache is similar to, say, Python's .pyc files.

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

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.

It's probably just the switch (didnt read the article). A 2-3x performance improvement is reported in almost every project that makes the switch.

Significant improvement in response times, TPS, and memory usage are pretty universally observed when switching from PHP5.x to PHP7...

https://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...

A fun thing about that slide deck: the memory use reduction is actually even better, because allocation overhead isn't counted there.

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.

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

Were there major improvements to autoloading in PHP7?

I can't imagine that any of those performance gains were related to autoloading.

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.

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.

I like the performance of php 7 very much. It has/will have an impact on global warming.

The only frustrating thing about it is, that there was so much potential unused for so long. Manh k/mwatts of power for nothing.

Wow good for the environment :)

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.

> As you can see, the latency dropped to less than half, and the load average at peak is now lower than it’s previous lowest point!

the graph they're referencing shows the peak at higher than the previously lowest load. i guess "peak average" is the key to this.

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

Sorry for being a bit ignorant, but is there a point to use PHP 7 if you have HHVM?

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?

PHP 7 is the next upgrade from PHP 5? I am very new to PHP and learning from a book which is PHP 5.

Yes, but more or less everything you know about PHP 5 is still true and will work just fine in PHP 7.

https://wiki.php.net/rfc/php6#historical_context

http://php.net/manual/en/migration70.incompatible.php

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.

[0]: http://pastebin.com/raw/P6BTmceL

For the down voters please see [Petty Issues I have with PHP!](petty); and please reply.