Key Metrics & KPIs
Performance testing produces dozens of data points, but only a handful of metrics truly matter. Master Response Time, Throughput, Hits Per Second, Error Rate, the 90th Percentile, and Pacing Calculations to become a data-driven performance engineer.
Response Time
The round trip of a request — from the moment a user sends a request to the moment the complete response is received back.
Throughput
The amount of data (bits/bytes) received from the server per unit of time. Measures the server's data delivery capacity.
Hits Per Second
The number of successful HTTP requests hitting the server per second. A user action may generate multiple hits.
Connections
The number of active TCP/IP connections between virtual users and the server at any given moment during the test.
Error Rate
The percentage of failed requests out of total requests. High error rates indicate application instability or resource exhaustion.
90th Percentile
90% of all transactions complete within this response time value. This is the standard metric reported to clients.
Response Time — Deep Dive
Response Time is the round trip of a request. It is the most critical metric in performance testing because it directly impacts user experience. Response time is measured in seconds and is broken down into components:
Server Time
Time spent processing the request on the application server (business logic, database queries, computations).
Network Time
Time spent transmitting data across the network between client and server (latency, bandwidth limitations).
Client Time
Time spent rendering the response in the browser (HTML parsing, CSS rendering, JavaScript execution).
Key Distinction: A user action is a request. A successful request is a hit. One request may contain multiple hits (e.g., loading a page triggers requests for HTML, CSS, images, JS files).
Throughput & Hits/sec
Throughput is the amount of data (bits) received from the server. It indicates how much data the server can deliver under load. A healthy test shows throughput increasing proportionally with user load.
Hits Per Second measures per-second how many hits are happening against the server. This metric helps gauge the server's request processing capacity.
What to Watch For
Granularity Note: The minimum granularity for Throughput and Hits Per Second graphs is 5 seconds. For all remaining graphs, it is 1 second.
90th Percentile Calculation — Step by Step
90th percentile means that 90% of the transactions are completing within this response time limit. This is the standard metric reported to the client because it filters out extreme outliers while representing the realistic user experience.
Calculation Process
Step 1: Sort Response Times in Ascending Order
Collect all response times for a transaction and arrange them from lowest to highest value.
Step 2: Remove the Top 10% of Values
Take out 10% of the values from the bottom (highest values). These are the outliers that skew the average.
Step 3: Take the Highest Remaining Value
The highest value in the remaining set (after removing top 10%) is the 90th percentile response time.
Response Times (sorted ascending):
1.2s, 1.5s, 1.8s, 2.0s, 2.1s, 2.3s, 2.5s, 2.8s, 3.1s, 5.2s
Total values: 10
Top 10% to remove: 10 × 0.10 = 1 value (remove 5.2s)
Remaining values:
1.2s, 1.5s, 1.8s, 2.0s, 2.1s, 2.3s, 2.5s, 2.8s, 3.1s
90th Percentile = 3.1 seconds (highest remaining value)
→ "90% of transactions complete within 3.1 seconds"Why Not Average?
Averages are misleading because a few extreme outliers can dramatically increase the mean. The 90th percentile gives a more realistic picture of what most users actually experience.
Customizable Percentiles
Based on client requirements, you can generate 80%, 85%, 90%, 95% or any other percentile. The Analyzer Properties panel allows you to configure this. The industry standard is 90%.
Pacing Calculations — Little's Law
Pacing calculations determine the delay between iterations to achieve the target transactions per hour (TPH). This is one of the most important calculations in performance testing and is frequently asked in interviews. Also referred to as Little's Law or "How to calculate TPH."
Example 1: Basic Pacing Calculation
Given: Target 1,800 transactions per hour | 1 script = 30 transactions | 1 iteration = 30 seconds
Step 1: Calculate Total Iterations
Total Iterations = Target Transactions ÷ Script Transactions = 1800 ÷ 30 = 60 iterations
Step 2: Calculate Time for Target Iterations
Target Iteration Time = Total Iterations × 1 Iteration Time = 60 × 30 = 1800 seconds
Step 3: Calculate Remaining Time
Remaining Time = Target Duration − Target Iteration Time = 3600 − 1800 = 1800 seconds
Step 4: Calculate Pacing
Pacing = Remaining Time ÷ Target Iterations = 1800 ÷ 60 = 30 seconds
Iteration Time = Script Time + Pacing = 30 + 30 = 60 seconds/iteration
Total Transactions = (3600 ÷ 60) × 30 = 60 × 30 = 1800 transactions ✓
The pacing of 30 seconds successfully generates 1,800 TPH.Example 2: Multi-User Pacing Calculation
Given: Target 3,000 transactions per hour | 1 script = 60 transactions | 1 iteration = 10 seconds | 10 users | Duration = 1 hour
Step 1: Calculate Total Iterations
Total Iterations = Target Transactions ÷ Script Transactions = 3000 ÷ 60 = 50 iterations
Step 2: Calculate Per-User Iterations
1 User Iterations = Total Iterations ÷ Number of Users = 50 ÷ 10 = 5 iterations per user
Step 3: Time for Target Iterations (adjusted)
Time = (Per-User Iterations − 1) × Iteration Time = (5 − 1) × 20 = 4 × 20 = 80 seconds
Step 4: Calculate Remaining Time
Remaining Time = Target Duration − Target Iteration Time = 3600 − 80 = 3520 seconds
Step 5: Calculate Pacing
Pacing = Remaining Time ÷ Per-User Iterations = 3520 ÷ 5 = 704 seconds
Important Note: Whenever you are dealing with a minimal number of users and minimal number of transactions, you must reduce one iteration from the target iteration count in the time calculation (Step 3). This accounts for the fact that the first iteration doesn't need pacing before it.
Complete Pacing Formula Reference
Formula Set 1 — Iteration-Based
P = R / I P → Pacing (seconds) R → Remaining Time (seconds) I → Number of Iterations
R = D - (T × I) D → Duration (total test time in seconds) T → Time per iteration (seconds) I → Number of Iterations
I = T / S I → Number of Iterations T → Target Transactions (total target) S → Script Transactions (per script)
Formula Set 2 — User-Based
Users = TP × (R + T) TP → Throughput per second R → Response Time (seconds) T → Think Time (seconds)
P = R + T P → Pacing (seconds) R → Response Time (seconds) T → Think Time (seconds) Note: This simplified formula works when targeting a specific throughput with a known response time.
Complete Metrics Reference Table
| Metric | Definition | Unit | What to Monitor |
|---|---|---|---|
| Response Time | Round trip time of a request from client to server and back | Seconds | Should stay within SLA; watch for spikes under load |
| Throughput | Amount of data (bits) received from server per unit time | Bytes/sec | Should increase with users; flat = bottleneck |
| Hits Per Second | Number of successful HTTP requests per second | Hits/sec | Should scale with users; drops = server limit |
| Connections | Active TCP/IP connections between VUsers and server | Count | Watch for connection pool exhaustion |
| Error Rate | Percentage of failed requests out of total requests | Percentage | Should be < 2%; high rate = instability |
| 90th Percentile | 90% of transactions complete within this time | Seconds | Report to client; more reliable than average |
| Elapsed Time | Total test duration including ramp up + steady + ramp down | Seconds | Starts when you hit the start button |
| Transactions/sec | Number of completed transactions per second | TPS | Key goal metric; correlate with response time |
Controller Run-Time Metrics
During test execution, the Controller Run tab displays real-time graphs and statistics. Key metrics to monitor during a running test:
Ramp Up
Gradually increasing load against the application. Users are added at a controlled rate.
Steady State
The "duration" or "standalone" period where all users are active and metrics are measured.
Ramp Down
Gradually reducing load from the application. Users exit gracefully after completing iterations.
Elapsed Time
Total test duration that includes ramp up + steady time + ramp down. Starts when you hit start.
Interview Questions — Metrics & Pacing
Q: How do you calculate pacing / TPH?
Use the 4-step formula: (1) Total iterations = target transactions ÷ script transactions, (2) Time for iterations = iterations × iteration time, (3) Remaining time = duration − iteration time, (4) Pacing = remaining time ÷ iterations. Demonstrate with the 1800 TPH example.
Q: What is the difference between a request and a hit?
A user action is a request. A successful request is a hit. One request may contain multiple hits — for example, loading a web page sends one request but generates hits for HTML, CSS, JS, and image files.
Q: Why do we report 90th percentile instead of average?
Averages are misleading — a few extreme outliers can dramatically increase the mean. The 90th percentile filters out the top 10% of extreme values and reports the worst-case experience for 90% of users. Based on client needs, you can also generate 80%, 85%, or 95% percentiles.
Q: What does it mean when throughput is flat but users are increasing?
This indicates a bottleneck. The server has reached its maximum data delivery capacity. Further investigation is needed — check CPU utilization, memory, database connections, or application thread pools to identify the constraint.
Q: What is Little's Law in performance testing?
Little's Law states: Users = Throughput × (Response Time + Think Time). It relates the number of concurrent users to the server's processing rate and the time each user spends in the system. It's the foundation for all pacing calculations.