Site Performance and APM

Application Performance Monitoring tells you where your site's time actually goes: response time percentiles, the slowest URLs, the slowest database queries, and how hard PHP is working. This guide covers enabling APM, reading each panel, and acting on what it shows.

Where APM Lives in KPanel

1. Sign in to KPanel.
2. Click Websites in the left sidebar, then click the site.
3. In the site's tab strip, open WordPress, then APM.

The direct address is /websites/<site-id>/performance.

Turning APM On

APM is off until you enable it. On an eligible plan the page shows an Application Performance Monitoring card with an Enable APM button.

Enabling it adds a lightweight access log and a slow-request tracker at the PHP worker level. It does not inject anything into your pages and adds no work to a visitor's request, so it is safe to leave on permanently.

Once enabled the page shows an APM Active pill with the date it was switched on, a Refresh button, and a Disable APM button. Metrics only appear after real traffic arrives, so a quiet site shows Waiting for requests for a while.

Response Times

The first card holds four figures from the last hour, with the request count and the capture time in its header.

Each tile is colour-coded so you can read the state without knowing the thresholds.

Read the percentiles together, not separately. A good median with a terrible P95 means most requests are fine and a minority are painful, which is the classic signature of one slow page, one slow query, or a cache that misses on certain URLs. A bad median means the whole site is slow and the cause is usually structural: an undersized plan, a heavy theme, or caching that is off.

The 5xx error rate is the one figure that should be zero. Anything sustained above zero means visitors are seeing failures.

PHP Workers

The PHP Workers card shows three numbers:

• Active Workers: how many PHP processes are currently handling requests.
• Slow Requests: requests that exceeded the slow-request threshold and were logged.
• Total Handled: connections accepted since the pool started.

Active workers is a saturation signal. If it sits pinned near its ceiling during normal traffic, requests are queueing behind PHP, and every response time on the page above is partly queue time. That is a capacity problem, not a code problem, and the fix is a larger plan or less work per request.

A climbing slow-request count with a stable request volume means something has become expensive.

Slowest Endpoints

This card lists your slowest URLs by P95 response time, each with a bar, the P95 in milliseconds, and how many calls it received. Colour marks the worst offenders.

Read it as a shortlist, not a leaderboard. What you want is the intersection of slow and frequently called: a page that takes four seconds and is hit twice a day matters far less than one that takes 900 milliseconds and is hit ten thousand times.

Common culprits:

• Search pages that scan without an index.
• Category and archive listings that build large queries per request.
• Cart, checkout, and account pages, which are never cached because they are per-visitor. See Site Caching for which paths bypass the cache by design.
• Admin URLs, which are always dynamic.
• Anything calling an external API inside the request, where you are measuring somebody else's server.

Slow Queries

The Slow Queries card lists database queries averaging over 100 milliseconds, taken from the database's own performance data. Each row shows the average time, the maximum time, the call count, and the normalised query text.

The query text is a digest, with literal values stripped, so the same query with different parameters groups into one row. That is what makes the call count meaningful.

Fixing slow queries is usually one of three things: adding an index the query needs, reducing how often the query runs by caching its result, or removing the plugin that generates it. A query with a very high call count and a moderate average is often worse in aggregate than a single dramatic outlier.

If both the endpoints and the queries lists come back empty, the card says no slow requests were detected, which means everything in the last hour was inside normal thresholds.

Using APM Well

Take a baseline. Look at the numbers when the site is healthy, so you know what normal looks like. A P95 of 700 milliseconds means nothing until you know it used to be 300.

Change one thing at a time. Enable a cache, refresh, and compare. Deactivate a suspect plugin, refresh, and compare. Batched changes give you no signal.

Refresh deliberately. The Refresh button re-reads the metrics on demand. The figures cover the last hour, so give a change a little time before judging it.

Look outside APM too. APM measures your application. If the problem is the network or the edge rather than the code, Site Traffic Analytics and Site Uptime Monitoring will show it instead.

Troubleshooting

The page shows an upgrade panel. APM is included with Managed WordPress Pro. On other plans it is not available.

APM is on but there are no metrics. No traffic yet. Metrics appear once the site receives requests.

Response times are fine in APM but the site feels slow. APM measures server-side time only. Time spent downloading images, running JavaScript, and loading fonts in the browser is invisible here. If server time is good and the page still feels slow, the problem is in the front end or in what you are asking the browser to fetch.

P95 got worse after a plugin update. Check the slowest endpoints list, then the slow queries list. A plugin that added a query to every page load will show in both.

Everything is slow all the time. Check PHP workers for saturation first. If workers are pinned, add capacity or reduce work per request before optimising anything else.

Errors above zero. Fix these before chasing milliseconds. Start with your logs, and use the Troubleshoot with Kora button on the site's Error pages tab, which asks Kora to read your error logs and recent failures for you. See Custom Error Pages.

Related Pages

• Site Caching is usually the single largest win for a WordPress site.
• Site Security for vulnerability and malware scanning on the same site.
• Taking a Backup before you start removing plugins.