The key metrics to measure during performance testing are response time (as percentiles, not just the average), throughput, error rate and the number of concurrent users, together with resource metrics on the servers: CPU, memory, disk, network and database health. The first group tells you what users experience, and the second tells you why. Pick the targets before the test runs, and read every result against them.
Key takeaways
- Response time alone hides the problem. Track throughput, error rate and resource use alongside it.
- Percentiles tell you what users actually experience; averages hide the slow tail.
- Decide which metrics matter before the test runs, or you will rationalise whatever the run produced.
What are the key metrics in performance testing?
Most performance metrics fall into two groups. Client-side (load) metrics are measured by the load generator and describe the service your users get. Server-side (resource) metrics are measured on the system under test and describe why it behaves that way. A slow response time with idle CPUs points somewhere very different from a slow response time with CPUs at 100%.
| Metric | What it tells you | Unit |
|---|---|---|
| Response time | How long a request takes from sending to the last byte of the response | ms or s, as percentiles |
| Latency | How long until the first byte arrives (network plus server think time) | ms |
| Throughput | How many requests (or transactions) are completed per unit of time | requests/s |
| Error rate | Share of requests that failed | % of requests |
| Concurrent users | Virtual users active at the same moment | count |
| Bandwidth | Data moved per second | KB/s or Mbit/s |
Which load metrics should I track?
Response time
Response time is the time from sending a request until the whole response has been received. JMeter calls this elapsed time and measures it from just before sending the request to just after the last response has been received (jmeter.apache.org glossary, read 2026-10-23). Report it as a median and as high percentiles such as p90, p95 and p99, plus the maximum.
Percentiles, worked example. Ten response times in milliseconds: 120, 130, 140, 150, 160, 170, 180, 200, 450 and 1,200.
- The mean is 2,900 / 10 = 290 ms.
- The median is (160 + 170) / 2 = 165 ms.
- The 90th percentile, using JMeter’s definition “90 % of the samples took no more than this time”, is 450 ms (the 9th of 10 sorted values).
- The maximum is 1,200 ms.
The mean of 290 ms describes none of the requests: most were far faster, and one was four times slower. See why percentiles are more useful than averages for more.
Latency
Latency is the time until the first byte of the response arrives. JMeter defines it as the time from just before sending the request to just after the first response has been received, so it includes server processing as well as the network. A response time that is much higher than latency means the body is large or slow to transfer. A high latency means either a long network path or a slow server.
Throughput and hits per second
Throughput is the number of requests completed per unit of time. JMeter reports it in requests per second, minute or hour, whichever keeps the number at or above 1. Hits per second counts the requests that reach the web server, and it includes every image, script and stylesheet a page loads, so it is always higher than page views per second. Throughput measured in data volume (KB/s) is a separate figure, usually called bandwidth. Do not mix the two when you compare tools.
Example: 4,800 requests completed in a 600 s test is 4,800 / 600 = 8 requests/s. At an average response of 50 KB, that is 8 x 50 = 400 KB/s, or about 3.2 Mbit/s.
Error rate
Error rate is the number of failed requests divided by the total requests during the test, as a percentage. Example: 12 failures out of 4,800 requests is 12 / 4,800 = 0.25%. A “failure” should include timeouts and unexpected status codes, and ideally responses with the wrong content, since a fast 200 with an error body is still a failure. Watch for the point where errors start: it shows the load at which the system stops coping. LoadFocus shows when errors appeared and how many virtual users were running at that moment (loadfocus.com/load-testing, read 2026-10-23).
Concurrent users
Concurrent users is the number of virtual users active at the same time. It is the input you set, not a result, but you need it to interpret everything else. How to calculate concurrent users shows how to derive it from real traffic.
Which server resource metrics should I track?
Resource metrics explain a bad load metric. Collect them on every server in the path during the test, and line them up by time with the load metrics.
| Area | Metrics | What to look for |
|---|---|---|
| Processor | CPU utilisation, run queue length, interrupts per second | Sustained high CPU while throughput stops growing. See CPU utilization in performance testing |
| Memory | Available memory, committed memory, private bytes, pages per second, page faults per second | Steady growth that never falls back (a leak) or heavy paging to disk |
| Disk | Disk busy time, disk queue length | A growing queue means requests wait for the disk |
| Network | Bytes sent and received per second, output queue length, dropped packets | Throughput flattening at the link’s capacity |
| Application | Thread count, active sessions, connection pool usage, garbage collection time | A pool at its maximum, or long collection pauses that line up with slow responses |
| Database | Query time, cache hit ratio, lock waits, slow queries, connections in use | Locks held for long periods, or a falling cache hit ratio as load rises |
A few definitions that are often mixed up. Private bytes are the memory a process has allocated that cannot be shared with others, and a steady rise over a long test suggests a leak. Memory pages per second counts pages read from or written to disk to resolve hard page faults, which is a sign the machine is short of RAM. The database cache hit ratio is the share of reads served from memory instead of disk. For the practical steps, see how to measure CPU and memory while running a load test.
How do I measure these metrics?
Measure load metrics with a load testing tool, and resource metrics with an agent or the operating system’s own counters (Linux top, vmstat and iostat, Windows Performance Monitor, or your monitoring stack).
For a quick latency breakdown of a single request, curl can print the phases:
curl -s -o /dev/null -w "dns=%{time_namelookup} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://example.com/For a load test, a JMeter plan gives you the load metrics directly:
- Download the latest Apache JMeter from jmeter.apache.org and start it.
- Add a Thread Group and set the users, ramp-up time and loop count or duration.
- Add HTTP Request samplers for the transactions you want to test.
- Add an Aggregate Report listener while you build the plan. Its columns include Average, Median, 90%, 95% and 99% Line, Min, Max, Error %, Throughput, and Received and Sent KB/sec.
- Run the real test in non-GUI mode (
jmeter -n -t plan.jmx -l results.jtl -e -o report/) and read the HTML report. The GUI is for building and debugging a plan, not for load.
LoadFocus shows response time, latency, hits per second, throughput per second, standard deviation and the 50th, 90th and 99th percentiles for every run, from 25 cloud regions, with up to 20,000 concurrent virtual users on paid plans (loadfocus.com/load-testing, read 2026-10-23). You can set pass or fail thresholds on p95 and p99 response time, error rate and minimum throughput. The comparison of two runs is described in the post on the baseline comparison feature.
What is a good target for each metric?
There is no universal standard, and any table that claims one for “10,000 concurrent users” is guessing. Targets come from what your users tolerate and what you promise in an SLA or internal objective. A starting point is Jakob Nielsen’s long-standing response limits: about 0.1 s feels instant, 1 s keeps the user’s flow of thought, and 10 s is the limit of keeping their attention (nngroup.com, read 2026-10-23). Anchor your own targets there, then write them as a metric, a percentile and a condition. An illustration of the format, not a standard:
| Metric | Example target |
|---|---|
| Response time | p95 under 800 ms at 500 concurrent users |
| Error rate | below 0.5% over the full test |
| Throughput | at least 200 requests/s at peak |
| CPU | below 70% on application servers at peak |
Establish a performance baseline first, so you know what “normal” is before you set a target. For how to build the test itself, see how to design effective load testing scenarios.
Best practices for accurate measurement
- Decide the metrics and targets before the run, not after you see the numbers.
- Use realistic data and a realistic mix of requests, and a ramp-up that matches how traffic actually grows.
- Repeat each test at least three times and compare, since one run can be skewed by a noisy neighbour or a cold cache.
- Keep the environment the same between runs, and note every change you make.
- Watch the load generator: if its own CPU or network is saturated, your response times include its delay.
- Line up client and server metrics by time, so you can see what the server was doing when a slow response was recorded.
- Read percentiles, error rate and resource use together, never response time alone.
Written by Chris R.
Frequently Asked Questions
What metrics are monitored in performance testing?
The core set is response time (as percentiles), latency, throughput, error rate and concurrent users, plus server resource metrics: CPU, memory, disk, network and database performance.
What are the KPIs for performance testing?
The most common KPIs are p95 or p99 response time, error rate, throughput and resource utilisation at peak load. Each should have a numeric target agreed before the test.
What is the 90th percentile in performance testing?
It is the response time that 90% of requests were at or below. If the 90th percentile is 450 ms, nine out of ten requests finished in 450 ms or less, and one in ten took longer. It is a better view of the typical slow request than the average.
What is the difference between latency and response time?
Latency is the time until the first byte of the response arrives. Response time is the time until the whole response has arrived, so it is latency plus the time spent receiving the body.
What is the difference between a KPI and an SLA?
A KPI is a metric you track to judge performance, such as p95 response time. An SLA is a commitment to a customer about the level of service, such as “p95 under 800 ms and 99.9% availability”. KPIs are how you check that you are meeting the SLA.
How many concurrent users can a system handle, and what are the standards for 10,000 users?
There is no industry standard for response time or error rate at 10,000 concurrent users, because it depends on what each user does. The load that 10,000 users create depends on think time. With a think time of 30 s and a 1 s response, each user makes one request per 31 s, so 10,000 users produce about 10,000 / 31 = 323 requests per second. Set targets from your own SLA and test at that rate.
How do I benchmark performance testing results?
Run a baseline test on a known build, record the metrics, and compare every later run against it under the same conditions. Compare against competitors or published figures only when the test conditions match, which they rarely do.
Sources
- Apache JMeter user manual: glossary (elapsed time, latency) and component reference (Aggregate Report) (jmeter.apache.org/usermanual, read 2026-10-23).
- Nielsen Norman Group, “Response Times: The 3 Important Limits” (nngroup.com, read 2026-10-23).
- LoadFocus load testing page (loadfocus.com/load-testing, read 2026-10-23).
