Why JMeter’s Reported Throughput Can Be Misleading: Client‑Side Timing Effects Explained

JMeter’s reported throughput can be deceptive because it measures the total time spent on the client machine rather than the pure server response time. The classic model for calculating throughput (TPS or QPS) is: tps = Thread / AVG(t) or tps = COUNT(request) / T In the first test case, with an average response time of 593 ms and 100 concurrent threads, the calculated throughput is 168.63, which matches JMeter’s 166.4 value closely. However, in the third case (100 threads, 791 ms average), the calculated throughput is 126.42 while JMeter reports only 92.3, showing a large discrepancy.

The root cause was identified as heavy use of regular‑expression matching in the post‑processor, which adds significant client‑side processing time. To demonstrate this, a single‑thread script was executed ten times, yielding an average response time of 207 ms and a JMeter‑reported throughput of 4.8, which aligns with the theoretical 4.83.

When a Groovy post‑processor introduced a 500 ms sleep per iteration (still single‑thread, ten requests), the average response time remained around 193 ms, but JMeter’s reported throughput dropped to 1.5. Adding the intentional 500 ms wait to the measured 193 ms (500 ms × 9/10 ≈ 450 ms) gives an adjusted throughput of 1.54, matching JMeter’s figure. This confirms that JMeter includes the entire client‑side loop time in its throughput calculation.

Consequently, any additional client‑side work—such as regex extraction, parameter validation, or variable assignment—reduces the reported throughput, making the load applied to the server appear smaller than configured. If the client’s processing overhead is substantial, the resulting throughput data should be treated as “fake” and corrected.

To obtain accurate performance metrics, the article recommends applying micro‑benchmark techniques to isolate and subtract client‑side processing time, as described in the linked references on micro‑benchmarking and reducing local measurement errors.

When significant discrepancies are observed, it is essential to adjust the results to avoid basing decisions on inaccurate data.