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 Kinsta’s 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:
- 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.).
- Enable the APM tool in MyKinsta and give it a few minutes to start collecting data. The APM tool can only record and analyze data while it’s enabled.
- Once the APM tool begins collecting data, recreate the issue to record the necessary information.
- If Redis is enabled on your site, make sure you use either the WP Redis or Redis Object Cache plugin (but not both). We may not be able to collect and show Redis data from other plugins in Kinsta’s APM tool.
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 results in APM (WordPress Sites > sitename > 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.
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.
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.
Clicking on that span opens the Span details modal/pop-up and includes the stack trace of the span.
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.
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.
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.
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 (WordPress 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.
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.
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.
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.
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.
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 Kinsta’s 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.