Kinsta’s APM tool is a powerful tool for troubleshooting your website. This article will take you through a few different scenarios for troubleshooting performance issues on a site using the APM tool to investigate and analyze the issues.

If you’re not familiar with the settings and terminology within the APM Tool, check out our guide on How to Use the Kinsta APM Tool.

Getting Started

Before diving deeper into using the APM tool to troubleshoot an issue, there are a few steps you’ll need to take, regardless of the issue:

  1. Make sure you can recreate the issue if it isn’t currently happening. Look for patterns of when the issue occurs or if specific actions seem to trigger the problem (e.g. editing a page, adding a product to an ecommerce cart, uploading images, etc.).
  2. Enable Kinsta APM and give it a few minutes to start collecting data. The APM tool can only record and analyze data while it’s enabled.
  3. Once the APM tool begins collecting data, recreate the issue to record the necessary information.

Analyze Slow-Loading Pages or Actions

In this example, pages load quickly, but everything slows to a crawl when adding any product to the cart, whether it’s a simple or a variable product.

After adding a few products to the cart, we take a look at the Monitoring Results in Kinsta APM (Sites > sitename > Kinsta APM) and see the /single-product transaction is at the top of the list of Slowest transactions, with a maximum duration of over 5 seconds and an average duration of over 2 seconds.

Select the single-product transaction at the top of the slowest transaction list in APM.
Select the single-product transaction at the top of the slowest transaction list in APM.

Clicking on that transaction opens the Transaction samples modal/pop-up where we can select the slowest transaction (first in the list) to see more details.

Select the slowest sample in the transaction samples list.
Select the slowest sample in the transaction samples list.

This takes us to the Transaction trace timeline, where we can sort the transactions by Duration (time) to see which processes in this transaction sample are the slowest. Here we can see that the update_card_payment span is the slowest process in the timeline, taking up 5,002.21 ms of a 5,535.61 ms transaction.

The update_card_payment span takes up 5,002.21 ms of the transaction.
The update_card_payment span takes up 5,002.21 ms of the transaction.

Clicking on that span opens the Span details modal/pop-up and includes the stack trace of the span.

View the span details, including the stack trace.
View the span details, including the stack trace.

We can see the WordPress hook action:woocommerce_add_to_cart is associated with this span in the span details.

There are a couple of ways to track down what plugin or theme this is associated with.

If you’re comfortable with the command line, you can use the grep command to search for the update_card_payment function and see which plugin or theme files contain that function.

Alternatively, you can look at the WordPress tab under Monitoring Results and look for a plugin with a similar Total Duration and Max Duration. It will most likely be at the top of the list.

View the slowest WordPress plugins on the WordPress tab in Monitoring Results.
View the slowest WordPress plugins on the WordPress tab in Monitoring Results.

You can confirm the match by selecting the plugin in the Slowest WordPress plugins list. If the plugin isn’t listed in the WordPress plugin column in the Transaction samples modal/pop-up, select the slowest transaction sample to view the Transaction trace timeline.

Select the slowest transaction sample to view the Transaction trace timeline.
Select the slowest transaction sample to view the Transaction trace timeline.

Sort the timeline by Duration and look for the same function name (e.g. update_card_payment) to be at or near the top of the list when sorted.

Sort the timeline by Duration and look for the function name in the Spans column.
Sort the timeline by Duration and look for the function name in the Spans column.

Investigate Overall Slowness

Overall slowness on a site is often due to a plugin and is one of the first places you’ll want to check. If a plugin is causing your site to be slow, this can usually be identified by viewing the WordPress tab (Sites > sitename > APM > WordPress). In the screenshot below, note that the highlighted plugin’s total duration percentage is over 98%, and the max and average duration are pretty high.

View a plugin's total duration percentage, max duration, and average duration.
View a plugin’s total duration percentage, max duration, and average duration.

This indicates this plugin is the most likely source of overall slowness on the site. To confirm this, we can deactivate the plugin, observe the site’s performance, and check the results in the APM tool once again after enough data has been collected. If you’re sure the plugin is configured correctly but continues to cause slowness on your site, we recommend contacting the plugin developer to work with them on resolving the issue.

Pinpoint Intermittent Third-Party Issues

External requests are HTTP requests made by the site to another (third-party) server. Plugins or themes usually make these requests for loading scripts or stylesheets or communication with an API.

When troubleshooting a possible external issue, it’s important to note that the APM tool records slow external transactions on the server-side. Many external requests can be made from a site on the client-side, which wouldn’t be recorded in the APM tool. For investigating external requests on the client-side, you’ll need to use a tool like GTmetrix or your browser’s dev tools.

To view slow external requests, go to the External tab under Monitoring Results to view the Slowest external requests. In this example, we’ve noticed some slowness when uploading images in the media library, with some uploads taking 5 minutes or more to complete.

We begin by looking at what the external requests look like when we’re not doing anything more than logging into the WordPress dashboard. Before uploading images to the Media Library, POST requests to wp-cron are the slowest requests, with 273.78 ms max duration and 1,957.81 ms total duration.

Slowest external requests in APM.
Slowest external requests in APM.

When we upload several images ranging in size from 3MB-17MB, it takes several minutes for those to finish uploading. Looking at External requests again, we see that POST requests to smushpro.wpmudev.com are the slowest external requests, with a max duration of 1,703.14 ms and a total duration of 82,710.85 ms.

Updated slowest external requests after uploading and optimizing images.
Updated slowest external requests after uploading and optimizing images.

Clicking on that transaction opens the Transaction samples modal/pop-up where we can select the slowest transaction (first in the list) to see more details.

Select the slowest transaction sample in external requests.
Select the slowest transaction sample in external requests.

This takes us to the Transaction trace timeline, where we can sort the transactions by Duration (time) to see which spans are the slowest. Here we can see that several POST requests to smushpro.wpmudev.com are the slowest in this sample, with the total of those POST requests taking up 6,712.64 ms of a 7,168.58 ms transaction.

Viewing all requests to smushpro.wpmudev.com in a transaction trace timeline.
Viewing all requests to smushpro.wpmudev.com in a transaction trace timeline.

We can also observe that the duration of each request varies significantly, with the shortest request only taking 138.2 ms and the longest taking 1,703.14 ms. So, while the Smush plugin is optimizing our images, each of those images spawns an external request, which adds up and can slow things down on the site.

In this case, optimizing our images before uploading instead of relying on a plugin for image optimization would significantly reduce our external requests. This is one of those cases where we’ll need to decide which is more important, convenience or site performance. We can keep the plugin if we’re okay with the necessary slowness caused by the external requests. If we would prefer or need to improve our site performance, removing the plugin and optimizing our images before uploading will be our best option.

Summary

Using the strategies from the examples above, you can use the Kinsta APM tool to debug performance issues on your site. Each situation and site is different, but you can apply the general troubleshooting methods here to help you or your developer track down performance issues on your site.