New Relic APM is a powerful tool that provides insight into the inner workings of WordPress sites to identify plug-ins, theme template files, database queries, external calls, or coding errors that cause performance problems with customer sites.
, however, getting New Relic running is just the beginning. If you have never used New Relic APM (even if you have), it may be difficult for you to make the most of this powerful tool. In this tutorial, we will show you how to use New Relic APM to diagnose and fix performance problems on WordPress sites.
summary
New Relic APM
New Relic APM overview
so what is New Relic APM? For our purposes, the following definition is appropriate:
New Relic APM is a Web application that provides detailed information about the performance of the WordPress site.
you can install New Relic by adding extensions to PHP. The extension listens for each request processed by PHP and sends that information back to the New Relic dashboard. New Relic then organizes this information into a series of charts and graphs that you can use to diagnose performance problems with your site. It is important to note that HHVM does not support New Relic.
gives us a quick look at the main data visualization of New Relic.
Overview
New Relic APM Overview
overview provides a quick snapshot of the overall performance of the site. You won’t diagnose specific problems from this screen, but a convenient compilation that shows how PHP, MySQL, and external calls work together can point you in the right direction.
learns more about the APM overview page.
transactions
New Relic Transactions Tab
The Transactions tab is the most useful tab in New Relic.
learns to like the transactions tab, and you will be able to learn more about slow transactions to identify database calls, external resources, or code bottlenecks that slow down the site. What is particularly interesting in the transaction view is the slow Transactions list. To view the list, scroll down to the bottom of the transactions tab and look at the lower right of the page.
New Relic Transactions tracks
here, and you will find a list of the slowest transactions captured by New Relic. We will not spend more time on this section now, but we will explain how to use this section to diagnose problems with your site later.
learns more about the New Relic APM transaction page. The
WordPress hook
WordPress hook
WordPress hook tab provides visualization of the time consumed by all PHP functions triggered by the WordPress operation hook. This information is useful to experienced developers who can use it to work backwards from overloaded hooks to identify functions triggered by hooks.
WordPress plug-ins and theme
WordPress plug-ins and theme
WordPress plug-ins and theme tabs show how much PHP processing time is consumed by plug-ins and active themes. If a single plug-in or your site theme consumes a lot of time, this page can help you quickly find the plug-in or theme that is causing the problem.
needs to note that WordPress plug-ins and theme tabs in New Relic are the most likely to be abused. When
investigates Web site performance problems, it’s easy to check this tab first by default, and then simply deactivate the most time-consuming plug-ins. However, doing so ignores valuable information found elsewhere in New Relic. This is similar to treating symptoms, rather than digging and finding the root cause. The
plug-in may run slowly due to misconfiguration issues, such as membership management plug-ins due to incorrect SMTP port numbers. Or the plug-in may not be uninstalled correctly. This is the type of information you might get by drilling for slow transactions in the transactions tab, and you can never solve the problem by simply disabling the slowest plug-ins reported by New Relic.
therefore, be familiar with this tab, but do not exclude the rest of the information provided by New Relic.
Database
New Relic MySQL Overview
Database tab, you can identify the database tables and types that take up most of the time. New Relic associates this information with the transaction that makes these queries. You can use this information to identify database tables that may need to be optimized and template files that impose excessive load on the database.
external services
New Relic external services
- most WordPress sites rely on many external services:
- plug-ins, themes, and core updates are provided by wordpress.org and plug-in and theme developers. Many of the
- plug-ins integrate with third-party API, such as WPMU DEV’s Smush image optimization plug-in (from the smushpro.wpmudev.org screenshot above). The
- chat plug-in is usually supported by external services. Many
sites are integrated with social media platforms to achieve optimal presentation and performance when sharing content on these networks.
when any of these external services stops responding in time, it can crash your entire site.
‘s external Services tab allows you to quickly see which external services take up most of your time. You can then use this information to determine whether it is a speed problem (slow service response) or a quantity problem (too many calls from external sources) and try to solve the problem.
Error Analysis
New Relic error Analysis
error Analysis tab reports PHP errors encountered while loading your WordPress site. Errors are grouped by category so that you can quickly see how many different types of errors are being generated. The error is also associated with the actual transaction that generated the error. If you select a specific error, you can also see the full stack trace of the transaction that generated the error.
treats error analysis as a better organized PHP error log. It can prove invaluable when trying to track down the file that produced the PHP errors and the transaction in which they occurred.
debugging slow-loading pages
the most common problem we use New Relic to debug is when a particular page or process takes too long to load. When this happens, the transaction tab in New Relic APM is almost certainly the first place to go.
- the procedure you need to follow to diagnose slow-loading pages is simple:
- slow replication transactions.
- finds the transaction in New Relic’s slow transaction list.
looks at the transaction summary and trace details to determine the reason for the performance degradation.
shows us an example and how to use New Relic to diagnose problems. Step 1 of
: copy transaction
Let’s look at an example. In this example, our client sees a slow load each time a single blog post is loaded. All other pages load normally, but individual articles take a few seconds to load.
, so the first step is the replication problem. In this case, this means visiting a single blog article several times to ensure that New Relic captures the necessary dates. Step 2 of
: after finding the slow transaction
replicates the slow transaction several times, go to New Relic and select the Transactions tab. Then scroll down until you see a list of slow transactions in the lower right of the New Relic dashboard.
New Relic transaction slow
Click the transaction you are debugging to view the details. Step 3 of
: view the transaction summary and trace details
after you select the transaction, the transaction summary is displayed.
slow transaction Summary
A summary allows you to view a snapshot overview of components that contribute to transaction time. In our example transaction, the call to the external resource www.googleapis.com is responsible for a transaction of 5000 milliseconds, which takes a total of 5350 milliseconds to complete.
although this is useful information, the tracking details tab will provide us with the details we need to know exactly what is happening. The
slow transaction tracking details
tracking details tab provides a hierarchical step-by-step waterfall diagram showing the functions, database queries, and external calls that PHP handles when generating the page.gapp_get_post_pageviewsin our sample transaction, the trace details show that the call to the Google parsing URL is the reason for blocking the process. If we work backwards from that request, it starts a PHP function called
. A quick Google search for the deal shows that it is part of the Google Analytics Post Pageviews plug-in. The plug-in is installed on the site and is used to add view counters to the sticky title bar.
New Relic has just allowed us to isolate the viewing counters in the sticky title bar as the main component, causing individual blog posts to be slowly loaded on related sites. Now the owner of the site knows exactly which component to target when trying to solve the problem of slow loading of individual blog posts. The overall slow
repair
- the second most common problem we troubleshoot for our customers is to complain about the slow loading of the entire site. When each transaction takes a lot of time to load, one of three things can happen:
- the site lacks server resources. The
- plug-in or activity theme is causing the problem. The
site database is trying to keep up with the query speed.
sites lack CPU or RAM, which can lead to overall slowness, and New Relic is not fixed on any single resource. So, if you do see the overall slowness and New Relic indicates that every part of the site is contributing, check the load on the server to see if it is caused by a shortage of server resources.
if your site has access to a large number of server resources, the next location you need to check to diagnose overall slowness includes WordPress plug-ins and themes tabs, external services tabs, and database tabs.
the following is an example of overall slowness that can be diagnosed using each of these tabs. Overall slowness caused by the
plug-in
when the plug-in causes the overall slowness, the symptoms vary depending on the activity performed by the plug-in. However, in many cases, you will find that a slow plug-in affects every page of the WordPress site. For sites with the data you see in the following figure, overall slowness is observed on each front-end page of the site.
below is New Relic’s evaluation of the performance of the site’s plug-ins.
WordPress plug-in
you can immediately see that the adinjector plug-in takes 15 times as long as the next slowest plug-in.
when you see such data, you may immediately think that the plug-in is improperly encoded or invalid. Although this is sometimes the case, it is not always the case. Plug-in misconfiguration, slow database, or slow response to external resources can cause the plug-in to consume a lot of time.
therefore, when you see a slow-responding plug-in, it’s best to check several other screens in New Relic for additional information. Before deciding whether to deactivate the plug-in is the best or the only way, you should check transactions, databases, and external resources. Overall slow
caused by
external services if the site relies on calls to external services to generate page views, and the service stops responding or takes a long time to respond, the result may be that the WordPress site stops loading completely.
The pictures on the top five external services
come from the same site where the screenshot of the slow plug-in above was made. As you can see, one external service accounts for too much of the total time spent waiting for the external service. The case of
illustrates why you need to look at the information in combination before you come to a conclusion. The service being invoked in this case is the developer of the plug-in identified in the last step.
this information adds some nuances to the situation. It is said that the problem is not the plug-in code. On the contrary, it seems that the plug-in makes a lot of calls to the developer’s website, and the combination of these calls can consume a lot of processing time.
if we go further and look at the slow transactions on this site, we can see that this external call seems to be checking the license status of the relevant plug-in, indicating that the license for this particular plug-in may have expired.
anyway, we can now tell the site owner that the adinjector plug-in is causing performance degradation, which is due to repeated calls to the developer’s website to check the plug-in’s license status. The overload of the
database leads to the overall slow
- optimization of the database may lead to the overall slow operation of the WordPress site. One of the optimizations we always recommend is to convert your database from MyISAM to InnoDB. In New Relic, this database-related slowness is likely to occur in two places:
- first, you’ll see a lot of MySQL activity in the overview.
second, you will see that one or more database tables take up a lot of time in the database tab.
starts with the overview screen, and a site with a difficult database may look like this:
network transactions take time
to better handle database tables or queries that are causing problems, go to the databases tab. The
MySQL Overview
Database tab indicates the types of tables and queries that consume the most time. If you select one of the entries in the list, you can see more details, including some sample queries.
slow query-the wp_options table
in this case, the data points to the data automatically loaded in the wp_options table. Sure enough, a quick analysis of the wp_ options table confirmed that nearly 250MB data was automatically loaded from the table, making the site an obvious candidate for database maintenance and optimization. Check out our more in-depth article on how to optimize wp_options tables and load data automatically.
Summary
