Correct for coordinated omission in JMeter: correction factor, lost requests, adjusted response times, and required threads. Free client-side tool.
JMeter Coordinated Omission Calculator
Section titled “JMeter Coordinated Omission Calculator”When the server can’t keep up with your target throughput, JMeter’s Thread Group silently drops requests instead of queuing them. This produces artificially low response times and inflated percentiles. Enter your target RPS, actual RPS, average response time, and test duration to compute the correction factor, lost requests, corrected response time, and the thread count you should have used.
Intended throughput (what you configured)
Measured throughput from the test run
Average response time from the test
Total test duration in seconds
Correction factor-
Lost requests-
Corrected avg RT-
Needed threads-
Overload severity-
Heuristic correction based on Gil Tene's queue-depth model. Validate with How NOT to Measure Latency. See Best Practices and Thread Calculator.
What is coordinated omission?
Section titled “What is coordinated omission?”Coordinated Omission is a measurement bias that occurs when a load generator schedules the next request at a fixed interval (e.g., every 20 ms for 50 RPS) but fails to account for the time already spent waiting on the previous request.
When the server degrades:
- Threads get “stuck” waiting for slow responses.
- Fewer requests are sent than the target rate.
- The “missing” requests are silently dropped - never queued.
- Measured throughput drops, but response times look artificially low.
Example: You target 50 RPS with 100 threads. Server degrades to 5-second response time. Instead of 50 RPS, you get ~20 RPS (100 threads / 5s). Your throughput drops by 60%, and your average response time doesn’t reflect what real users would experience.
How the correction works
Section titled “How the correction works”The calculator uses the queue-depth model from Gil Tene’s talk How NOT to Measure Latency:
correction_factor = target_RPS / actual_RPSlost_requests = (target_RPS - actual_RPS) × duration_secondsqueue_depth = (target_RPS - actual_RPS) × (avg_RT_ms / 1000)corrected_RT = avg_RT_ms + (queue_depth × avg_RT_ms)needed_threads = target_RPS × (avg_RT_ms / 1000)When target_RPS > actual_RPS, the correction factor tells you how much your
measured metrics are skewed. A factor of 2.5x means your real response time is
roughly 2.5× what JMeter reported.
Example
Section titled “Example”| Target RPS | Actual RPS | Avg RT | Duration | Correction | Lost reqs | Corrected RT |
|---|---|---|---|---|---|---|
| 50 | 20 | 5,000ms | 60s | 2.5x | 1,800 | ~12,500ms |
| 100 | 80 | 3,000ms | 120s | 1.25x | 2,400 | ~3,750ms |
| 200 | 200 | 500ms | 60s | 1.0x | 0 | 500ms |
What this does not include
Section titled “What this does not include”- Percentile correction - the queue-depth model corrects averages; for percentile correction, use a proper histogram (HdrHistogram) in your test.
- Think time / pacing - real users pause between actions; this calculator assumes continuous load.
- Server-side queuing - if the server itself queues requests, the corrected RT is a lower bound on what users experience.
- Distributed test aggregation - run this per engine and combine results.
Recommended workflow
Section titled “Recommended workflow”- Run your test and record target RPS, actual RPS, avg response time, and duration.
- Use this calculator to compute the correction factor and lost requests.
- If the factor is > 1.25, your results are significantly skewed.
- Re-run with more threads (use the Thread Calculator) or lower the target RPS.
- For accurate percentiles, instrument with HdrHistogram in your JMeter test.
Related reading
Section titled “Related reading”People Also Ask
What is coordinated omission in JMeter?
Coordinated omission is a measurement bias that occurs when a load generator schedules the next request at a fixed interval but fails to account for the time already spent waiting on the previous request. When the server degrades, threads get stuck, fewer requests are sent than the target rate, and the missing requests are silently dropped instead of queued. This produces artificially low response times and inflated percentiles.
How do I calculate the coordinated omission correction factor?
The correction factor is target RPS divided by actual RPS. For example, if you targeted 50 RPS but only achieved 20 RPS, the correction factor is 2.5x, meaning your real response time is roughly 2.5 times what JMeter reported. A factor above 1.25 indicates significant skew.
How many requests are lost to coordinated omission?
Lost requests equal target RPS minus actual RPS, multiplied by the test duration in seconds. For example, targeting 50 RPS but achieving 20 RPS over 60 seconds means 1,800 requests were silently dropped.
How do I fix coordinated omission in JMeter?
Use more threads so throughput stays at or above the target rate. The Thread Calculator can help you size threads correctly: threads approximately equals target RPS multiplied by average response time in seconds. Alternatively, lower your target RPS or use a proper load generation tool that handles queuing.
Does JMeter have a built-in coordinated omission fix?
JMeter does not automatically correct for coordinated omission in its standard Thread Group. The constant throughput timer helps maintain a target rate but does not queue or correct dropped requests. For accurate latency measurement, use HdrHistogram-based plugins or the Throughput Shaping Timer.
Was this page helpful?
Thanks for the feedback!Tell us what's missing on GitHub