Measuring PHP 7 Performance with New Relic: #NoBSBenchmarks

Earlier this summer we delivered New Relic APM Pro for all websites on the platform, giving all sites premium application performance analytics that would normally cost hundreds of dollars a month extra. Then, this August, we put PHP 7.0 into general availability, with a significant speed boost as one of the main selling points for upgrading to the new version.

Some things just go together. I'm extremely pleased to be able to use New Relic to offer real world proof points for PHP 7's performance. As you've already seen from our deep dives into using New Relic to understand Drupal and WordPress performance, we can get very accurate and detailed data. These are no-BS benchmarks.

Do you have your own interesting results from PHP 7 or another optimization? Grab a screenshot from your New Relic dashboard with the hour around the deploy, and tweet it out with the #NoBSBenchmarks hashtag.

A Big Complex WordPress Build

The first example to share is the site I tweeted about above, which is a complex, high-traffic WordPress build, and a great example how this update is a no-brainer. This site has a lot of traffic because it's been around for many years and grown to deliver more value to its audience. As is commonly the case for a long-lived site, it's been worked on by many different developers over time, most of that happening before it found a home on Pantheon.

As a result, there's a lot of "legacy" code, which means refactoring to improve performance is difficult without doing a complete overhaul. Hardly an ideal situation, but totally familiar to professionals in the real world, where navigating the trade-offs of scope, budget, and deadlines is a prerequisite to doing serious work.

PHP 7 is one of those rare and awesome moments where you can get a win from "down in the stack." It's not quite as turnkey as switching from spinning disks to SSDs, which we could just do for the whole platform without even telling anyone, but it's close. You still need to QA your site before rolling the new version into production, but WordPress core is 100% compatible with PHP 7, and most deprecation warnings from plugins or themes are easy to fix. It can be an hour's work or less to validate that everything works as expected, and then boom, 2x performance improvements.

Looking past those top-line numbers, I did a bit of digging into where the improvements really came from, and found some interesting results. New Relic offers out-of-the-box profiling of WordPress's hooks, plugins and theming framework, so you can see your top five most time-consuming of each. Some of the results were quite revealing. For example, here's the time consumed by the smart-youtube plugin:

There was a similarly dramatic improvement for respond-pro:

And if we take a look at the hook breakdown, after removing init and footer (which stayed the same, basically) there's a stark improvement for both the_content and wp_enqueue_scripts:

These are some serious specific gains that come in addition to the overall improved efficiency of execution, which explains why this site saw their performance literally double with just one deploy. Typically we expect a 50 to 60% speedup when sites upgrade from PHP 5.5 to 7.0, but we'll happily take 100%!

There's a lot more that developers can dig into in terms of understanding where the performance gains are coming from, and where there might be future gains to be found. I'm especially looking forward to analyzing this data across a large number of sites to spot common patterns (and anti-patterns) for plugin and hook performance. More on this soon.

Drupal 8: Migration Re-Installation and Admin Actions

Pantheon Agency and Community Engineer Steve Persch has been working a lot with Drupal 8 this year, and found some really great benchmarking insights recently. Projects involving Drupal 7 to Drupal 8 migrations are probably going to do a lot of re-installations in the life of the project. In Drupal 8 it is easier than ever to keep your configuration in code and create databases as part of a continuous integration process that migrates canonical data from the old site (Drupal 7). Steve goes in-depth on this idea over on his personal blog, if you want to know.

While this approach to a project keeps your process cleaner, the repeated re-installations of Drupal 8 can be time-consuming. PHP 7 to the rescue. Here's what repeated installations of Drupal core’s Standard profile look like. The time spent in PHP drops from 42 seconds to 24 seconds. That kind of difference really adds up in the life of a large project where this operation is happening again and again and again:

The Drupal Core installation process is a heavy workload in terms of initializing database tables, which new version of PHP can't do anything to speed up. However, it still manages to get the total install time under one minute based on improved code execution. You'll also notice the header for this graph is "non-web transaction time", which is because this process was testing scripted installs, meaning it used Drush. Yep, PHP 7 makes command line PHP faster too.

Steve also did some testing of another heavy workload in the admin area—this time on a fully built site with plenty of bells, whistles, and Views—as part of a pre-launch review. Using behat, he had an admin user perform the following actions:

• Create a blog node
• Saved the node as a draft with Workbench Moderation
• Moved the node to published
• Viewed a Workbench Moderation administrative listing

[Related] How Agencies Benefit from Pantheon High Performance Web Hosting

This is a great benchmark because it's the kind of workload that is unlikely to be improvable via caching. Creating content and moving it through a moderation process is the kind of activity that creates/overwrites/deletes the cache items that all the other transactions will read from (and be accelerated by).

Again, the time for database calls and external web requests are the same, but the PHP execution is significantly faster, exactly what we expect to see. PHP 7 offers a real win—again, with minimal cost to developers—for improving the administrative and editorial user experience on all your sites.

Upgrade Now, Feel the Win

Overall, the upgrade process for most sites to PHP 7 should be fairly painless. You can use a Multidev environment and try it out easily and safely. I've created a quick script to help you generate benchmark traffic in a fresh environment so you can get a sense of your before/after before going live. Code changes needed for compatibility (if any) happen in the same environment, so they're tracked into version control right alongside the pantheon.yml configuration file that sets the PHP version. Be sure to enable New Relic first so you can get a detailed look at your before and after results.

I'll have more to come as we are able to gather more data and do more testing. If you've got results you're personally proud of, grab a screenshot of New Relic and tweet it out with the #NoBSBenchmarks hashtag.

Related Information:

• New Relic & Drupal: Find Your Site's Slow Spots [BLOG]
• Troubleshooting WordPress Performance with New Relic [BLOG]
• spiderme.sh: Benchmarking for Website Performance on Pantheon [GITHUB GIST]
• Improve Performance with PHP 7: An Exclusive Look at How Cheeky Monkey Media Did It [BLOG]