Troubleshooting WordPress Performance with New Relic

New Relic dashboard

Thanks to our recent launch of New Relic Pro for Performance tiers and above, WordPress sites on Pantheon will now benefit from smarter troubleshooting. New Relic’s application performance monitoring tells you not just when your site is slow, but where your site is slow.

Here I will walk you through how to diagnose page load issues on a sample WordPress site using New Relic APM.

Example Site

I built a WooCommerce example site that has a page template showing the 25 best selling products. It's a pretty standard page and includes some details about each product, such as sale price, as well as a sidebar with recent Tweets.

Testing with 75 concurrent users averaged a 1.73s page load.

New Relic top 25 non-optimized

Learn how you can improve WordPress hosting performance with Pantheon.

External Services

Calls to external services, such as third-party APIs, can be very heavy.

Our example page loads the latest Tweets on every page load. This is inefficient and can block page rendering if the Twitter API is down or slow to respond.

New Relic web external specific screenshot

In most cases third party API responses can be safely cached. In our example caching the Twitter response for 5 minutes with the WordPress transient API makes a big difference.

Instead of 85 requests per second we make 5 requests every 5 minutes and our overall page load time is down. Caching API responses also helps avoid rate limits.

New Relic web external overview 5 min cache enabled

Modern PHP Version

After the Twitter API calls are cached the majority of the page load is still PHP (see previous image).

"One WordPress request on PHP 5.6 executes just under 100M CPU instructions, while PHP 7 only executes 25M to do the same job." (source)

PHP 7 is a lot faster. Upgrading from PHP 5.6 to PHP 7 provided a 38% increase in page speed without have to do any coding or make modifications to the site at all.

New Relic PHP 7 overview no annotation

N+1 Queries

A WP_Query call by itself can be heavy but even optimized queries can be have an impact on performance when many smaller tasks are called from inside a loop.

Fetching template parts, meta data, images, etc. all seem like small requests, but when they are inside a loop running 25, 50, 100+ times? Think of this like death by a thousand cuts.

Our example page makes 34 calls to get_term.

New Relic plus one before

The page displays categories and tags for each of the 25 products. 3-4 tags per post multiplied by 25 posts adds up.

By removing tags from the top 25 template we reduced get_terms calls significantly and increased our page load time even more.

New Relic top 25 tags removed

Object Caching

WordPress object cache is used for caching data which may be computationally expensive to regenerate, such as the result of complex database queries.

This can be WP_Query calls, fetching options, which are autoloaded by default, etc.

MySQL can be slow, especially for complex queries. Caching them provides a good performance boost since page loads will read from the cache instead of making another database query.

In our example, this is the list of top 25 products and their metadata, such as category and price.

"By default, the object cache is non-persistent…Cached data will not be stored persistently across page loads unless you install a persistent caching plugin." (WP_Object_Cache article)

I prefer Redis for object caching but you can also use memcached, APC or others. WordPress doesn't care which backend data store you choose.

Using an object cache will lessen the burden on the database, allowing you to scale to more users.

In our example site database, load decreased significantly when using Redis.

New Relic Redis disabled

WordPress transients cache to the database by default. Enabling an object cache will store transients in the new object store as well. Redis stores items in memory and is much faster than MySQL.

Full Page Cache

Full page cache is probably the best single thing you can do to increase your site performance.

PHP is an interpreted code language, which means it must be rendered into HTML. This usually happens on every page load.

Full page caching stores the HTML output from PHP and serves that directly to the user rather than re-interpreting PHP each page load.

Full page cache diagram

Images from http://book.varnish-software.com/4.0/chapters/HTTP.html

Serving cached pages is simple job, and other subsystems can do it much better than WordPress. A reverse proxy can deliver up to 200x improvement in speed and volume.

Most managed WordPress hosts will offer full page caching out of the box. Alternatively, you can use open source solutions such as Varnish and Nginx, or a commercial CDN, as your reverse proxy. Either way, your site will serve cached pages better and with more stability during traffic spikes than serving cached pages with WordPress.

After enabling Varnish on our example site, cache hits load in about 0.2s, compared to 1.7s for a page load from the server.

New Relic Varnish enabled

Full page cache is great for anonymous users and serving static pages. However, not everything can be handled with full page cache.

What happens when users need a unique experience or custom sessions, such as shopping cart data?

Full page cache is great, and absolutely necessary to scale your site, but isn't the only optimization you should make.

Overview

New Relic was able to help us pinpoint slow areas of our "Top 25" products page. Unoptimized testing with 75 concurrent users averaged a 1.73s page load.

New Relic overview unoptimized

75 concurrent users averaged a 20ms response, spiking at 824ms when cache expired.

New Relic overview optimized

Tuning New Relic for WordPress

Apdex Score

New Relic allows you to set an apdex score for your application. Apdex is a measure of response time based against a set threshold. It measures the ratio of satisfactory response times to unsatisfactory response times.

You define a response time threshold T. All responses handled in T or less time are considered satisfactory.For example, if T is 1.2 seconds and a response completes in 0.5 seconds, then the user is satisfied. All responses greater than 1.2 seconds are unsatisfactory.

Email Alerts

New Relic can send you email notifications when your application is in an unsatisfactory state. You can view the alert details with one click.

New Relic alert email

Alert Details

Alert details will tell you exactly when issues occurred. You can tie application performance issue with other data to determine the effect on your business.

New Relic alert history

Transaction Traces

Transaction traces allow you to see where parts of your application are slow. No more needle in the haystack.

New Relic transaction trace expanded

Key Transactions

New Relic allows you to set transactions as key transactions. These are used for business critical pieces of the application, such as checkout, or performance intensive items, such as search.

New Relic key transaction overview

You can set up alerts and adjust apdex score for key transaction. Site is up but checkout is slow? Get an email or text message.

New Relic key transaction alerts

Conclusion

I hope you can see the power of New Relic application performance monitoring. If you'd like to try it out, Pantheon offers New Relic Pro for free on the Performance tier and above. Check out our getting started guide to see how to add New Relic to your Pantheon site today.


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

Editor’s Note: This post was originally published on August 31st, 2016 and has been updated for accuracy and comprehensiveness.​

Topics Development, Ecommerce, Speed & Performance, Website Technology, WordPress