Here at Kinsta, our support engineers make use of New Relic APM every single day. It’s a powerful tool that drills down into the inner workings of a WordPress or any other website to pinpoint plugins, theme template files, database queries, external calls, or coding errors causing performance issues on our clients’ websites.
We pride ourselves on being developer-friendly managed WordPress hosting. So we don’t hog this powerful tool all to ourselves. On our platform, our users can add their own New Relic license so they can enjoy the same powerful visibility. If your hosting provider doesn’t offer New Relic integration, you can set it up yourself if your site is hosted in a private environment.
However, getting New Relic running is just the beginning. If you’ve never used New Relic APM (and maybe even if you have), you may want some help to get the most out of this powerful tool. In this tutorial our goal is simple: to show you how you can use New Relic APM to fix what ails your WordPress website. Ready to get nerdy? Let’s get to it!
A quick overview of New Relic APM
You install New Relic APM by adding an extension to PHP. That extension listens to every request processed by PHP and then sends that information back to the New Relic dashboard. New Relic then organizes that information into a series of charts and graphs that you can use to diagnose your website’s performance issues. (It’s important to note that New Relic isn’t supported on HHVM on PHP.)
Let’s take a quick tour through New Relic’s primary data visualizations.
Overview: The overview provides a quick snapshot of the overall performance of your website. You won’t diagnose specific issues from this screen, but the handy compilation showing how PHP, MySQL, and external calls are working together can point you in the right direction. Learn more about the APM overview page.
Transactions: The Transactions tab is the most useful tab in New Relic. Learn to love the transactions tab and you’ll be able to drill down into slow transactions to identify database calls, external resources, or code bottlenecks slowing down your site. Of particular interest within the transactions view is the list of slow transactions. To see the list, scroll down to the bottom of the transactions tab and look in the lower right-hand portion of the page.
Here you’ll find a list of the slowest transactions captured by New Relic. We won’t spend any more time on this section right now, but a little later we’ll explain how to use this section to diagnose your website’s woes. Learn more about the New Relic APM transactions page.
WordPress hooks: The WordPress Hooks tab provides a visualization of the time consumed by all of the PHP functions triggered via WordPress action hooks. This information can be useful to experienced developers who can use the information to work backwards from an overloaded hook to identify the functions that are fired by the hook.
WordPress plugins and themes: The WordPress Plugins and themes tab shows you how much PHP processing time the plugins and active theme are consuming. If a single plugin or your site theme is consuming a dramatically outsized amount of time, this page can help you quickly spot the plugin or theme causing the issue.
A word of caution: The WordPress Plugins and themes tab in New Relic can be misused. When investigating a website performance issue, it can be tempting to default to checking this tab first and simply deactivating the most time-consuming plugin. However, this ignores the valuable information found elsewhere in New Relic. It’s akin to treating symptoms rather than digging in and finding the root cause. Plugins may run slowly due to a misconfiguration issue, such as a membership management plugin running slowly due to the use of an incorrect SMTP port number. Or a plugin might not have been uninstalled correctly. You could probably derive this information by drilling into a slow transaction within the transactions tab, and you’ll never fix it by simply deactivating the slowest plugin. So get comfortable with this tab, but not to the exclusion of the rest of information provided by New Relic.
Databases: The Databases tab lets you identify the database tables and types of queries consuming the most time. New Relic ties this information back to the transactions making those queries. You can use this information to identify database tables that may require optimization and template files that are placing an outsized load on the database. Learn more about the New Relic APM databases page.
External services: Most WordPress websites rely on a number of external services:
- Plugin, theme, and core updates are delivered from wordpress.org as well as plugin and theme developers.
- Many plugins integrate with third-party APIs, such as WPMU DEV’s Smush image optimization plugin (wpmudev.org in the screenshot above).
- Chat plugins are generally powered by external services.
- Many sites are integrated with social media platforms for optimum presentation and performance when content is shared on those networks.
When any one of these external services stops responding in a timely fashion it can bring your entire website to a crashing halt.
The External services tab allows you to quickly see which external services are consuming the most time. You can then use that information to determine if it’s an issue of speed (the service is responding slowly) or quantity (there are too many calls to the external source) and work towards resolving the issue. Learn more about the New Relic APM external services page.
Error analytics: The Error analytics tab reports the PHP errors encountered while loading your WordPress site. The errors are grouped into classes, so that you can quickly see how many different types of errors are being generated. The errors are also tied back to the actual transactions that generated the errors. If you select a specific error you can also see a full stack trace for the transaction that generated the error.
Think of error analytics as a better-organized PHP error log. It can prove invaluable when trying to track down the files generating PHP errors and the transactions where those errors occur. Learn more about New Relic Error analytics.
Debugging slow-loading pages
The most common issue our team uses New Relic to debug is the case of a specific page or process that is taking an exceptionally long time to load. When this happens, the transactions tab in New Relic APM is almost certainly the first place to head.
Diagnosing a slow-loading page is pretty straightforward. If the offending transaction is one of the slowest on the page, you’ll see it right away. If it’s not, try this:
- Set up Key Transactions to highlight the most important transactions on the page.
- Exercise the problematic transaction on the page.
- Review the transaction summary and trace details to determine the cause of the slow performance.
Let’s look at an example of this and how New Relic can be used to diagnose the issue.
Step 1: Exercise the transaction. For example, our client loads slowly every time an individual blog post is loaded. All other pages load normally, but individual posts take several seconds to load.
The first step is to re-create the issue. In this case, that means visiting a single blog post a few times to ensure New Relic captures the necessary date. Note: If your site makes use of page caching, which is built into the Kinsta platform, you’ll need to clear the cache between each page load. Otherwise, you’ll end up loading the page from cache rather than having WordPress generate the page.
Step 2: Find the slow transaction. Once you’ve duplicated the slow transaction a couple of times, head to New Relic and select the transactions tab. Then scroll down until you see the list of slow transactions in the lower right-hand portion of the New Relic dashboard.
Click on the transaction you are debugging to see details.
Step 3: Review transaction summary and trace details. Once you select the transaction, a summary of the transaction will be displayed.
The summary lets you see a snapshot overview of the components that contributed to the processing time of the transaction. In the case of our example transaction, a call to an external resource, www.googleapis.com, is responsible for 5,000 milliseconds of a transaction that took a total of 5,350 milliseconds to complete.
While this is useful information, the Trace details tab will provide the details we need to see exactly what is happening.
The Trace details tab provides a hierarchical step-by-step waterfall showing the function, database queries, and external calls that PHP works through as it generates the page.
In the case of our example transaction, the trace details reveal that a call to a Google analytics URL is what is holding up the process. If we work backwards from that request, it is initiated by a PHP function named gapp_get_post_pageviews. A quick Google search for that transaction reveals that it is part of the Google Analytics Post Pageviews plugin. This plugin is installed on the site and used to add a view counter to a sticky header bar.
New Relic has just allowed us to isolate the view counter in the sticky header bar as the primary component contributing to the slow loading of single blog posts on the site in question. Now the owner of this site knows exactly what component to target in trying to resolve the slow-loading individual blog posts.
Fixing overall slowness
The second most common type of issue we troubleshoot for our clients is a complaint that the entire site is loading slowly. When every transaction takes a lot of time to load, one of three things is probably going on:
- The site is starved for server resources
- A plugin or the active theme is causing problems
- The site database is struggling to keep up with the rate of queries
At Kinsta, server resources issues are rare. We allocate CPU and RAM as needed and manage the overall load on our machines to make sure there are plenty of server resources available when your sites need them. However, if the site is starved for CPU or RAM, this can cause overall slowness that New Relic will not pin on any single resource. So if you do see overall slowness and New Relic indicates that every part of the site is contributing, check the load on your server to see if a shortage of server resources is to blame.
If your site has access to plenty of server resources, then the next places to check to diagnose overall slowness include the WordPress Plugins and themes tab, the External services tab, and the Databases tab.
Here are examples of overall slowness that can be diagnosed using each of these tabs.
Overall slowness caused by a plugin: When a plugin is causing overall slowness, the symptoms will vary based on the activity the plugin is performing. However, in many cases, you’ll find that a slow plugin will affect every page of a WordPress site. In the case of the site whose data you see in the image below, overall slowness was observed on every front-end page of the site. Here’s what New Relic had to say about the performance of the plugins on the site.
Immediately you can see that the adinjector plugin is consuming 15 times the amount of time as the next slowest plugin.
When you see data like this, it can be tempting to immediately dismiss the plugin as poorly coded or somehow ineffective. While this is sometimes the case, it is not always the case. Plugin misconfiguration, database slowness, or external resources that are slow to respond may cause a plugin to consume a lot of time.
So when you see a plugin that is responding slowly, it’s a good idea to check several other screens in New Relic to find additional information. The transactions, databases, and external resources should all be checked before deciding that deactivating the plugin is the best or only way forward.
Overall slowness caused by external services: If a site relies on a call to an external service in order to generate pageviews, and that service stops responding or takes a long time to respond, the result can be a WordPress website that stops loading entirely.
The image above is from the same site that produced the slow plugins screenshot. As you can see, a single external service is contributing an outsized amount to the total time spent waiting for external services.
This case shows why it’s necessary to view information in combination before arriving at a conclusion. The service being called in this case is the developer of the plugin identified in the previous step.
This information adds some nuance to the situation. It isn’t the code of the plugin that is the issue, per se. Rather, it looks like the plugin makes lots of calls to the developer’s website and these calls together are consuming a lot of processing time.
If we take things one step further and look at a slow transaction for this site, we can see that this external call appears to be checking on the license status of the plugin in question, which suggests that the license for this particular plugin may have expired. In any event, we are now able to advise the owner of this site that the adinjector plugin is causing the slow performance, and the slow performance is due to repeated calls to the developer’s website to check on the status of the plugin’s license.
Overall slowness caused by an overwhelmed database: A poorly optimized database can cause overall slowness on a WordPress site. One optimization we recommend is to convert your database from MyISAM to InnoDB. In New Relic, this database-related slowness will most likely show up in two places:
- You’ll see an outsized amount of MySQL activity in the overview.
- You’ll see one or more database tables consuming a lot of time in the databases tab.
Starting with the overview screen, a site with a struggling database might look something like this:
To get a better handle on which database table or query is causing the issue, head for the databases tab.
The databases tab will point out the table and type of query consuming the most time. If you select one of the entries in the list, you can see more detail, including some sample queries.
In this case, the data points a finger at autoloaded data in the wp_options table. Sure enough, a quick analysis of the wp_options table confirms that nearly 250 MB of data are autoloaded from this table, making this site an obvious candidate for database maintenance and optimization. (Check out Kinsta’s more in-depth post on how to optimize your wp_options table and autoloaded data.)
Now get debugging!
New Relic can be a valuable tool for identifying performance bottlenecks on your WordPress website. To get the most out of New Relic, it’s critical that you know WordPress, understand the information each tab is reporting, and see how all of the information is interrelated. You can learn more at New Relic’s WordPress-specific functionality documentation page.