Next Practical Step
Run a CLI pilot, capture average RT, size threads with the Thread Calculator, then compare achieved hits/s on the HTML dashboard.
Fix JMeter throughput stuck below target RPS: thread sizing, response time growth, listeners, think time, coordinated omission, and injector limits.
Throughput stuck / not reaching target RPS
Section titled “Throughput stuck / not reaching target RPS”Symptom
Section titled “Symptom”- You aimed for a target requests per second (or “users”) but the dashboard hits/s or throughput plateaus lower
- Active threads may be high while throughput stays flat
- Latency percentiles rise as you add threads
- Results can look “too good” if you under-issue load relative to the schedule (coordinated omission)
Common causes
Section titled “Common causes”| Cause | What to check |
|---|---|
| Not enough threads for target RPS | Little’s Law style sizing: threads ≈ RPS × response time (seconds) when busy (Thread Calculator) |
| Response time grew under load | Server saturation; each thread completes fewer iterations |
| View Results Tree / heavy listeners | Injector CPU burned on UI I/O (best practices) |
| Think time / timers | By design lower RPS; expected for paced users |
| Assertions and scripting cost | Too many expensive checks/scripts per sample |
| Injector CPU, NIC, or heap pressure | One machine cannot generate the offered load |
| SUT throttling | Rate limits, pool exhaustion, 429/503 |
| Ramp still running | Steady-state not reached yet |
Official best practices: incorrect thread sizing contributes to coordinated omission and inaccurate results. Use CLI for real load: jmeter -n -t plan.jmx -l results.jtl.
Fix (ordered)
Section titled “Fix (ordered)”- Measure average response time with a small pilot under CLI.
- Estimate threads with the Thread Calculator; add ramp-up (avoid 0-second ramp to huge threads).
- Disable heavy listeners; write results with
-lonly. - Run long enough to leave ramp and warm-up.
- Compare achieved hits/s to target; if RT rose, recompute threads or lower target.
- Use the Coordinated Omission helper when actual RPS is below target RPS to quantify skew.
- Check injector CPU and GC; raise heap only if needed (Heap Estimator), or split engines (distributed testing).
- Inspect SUT metrics (CPU, DB pools, rate limits) before adding infinite threads.
- Gate CI on error % and percentiles, not only “threads configured” (CI/CD, APDEX/SLOs).
Related tools and topics
Section titled “Related tools and topics”| Resource | Use when |
|---|---|
| Thread Calculator | Initial concurrency |
| Coordinated Omission | Actual RPS below target |
| Best practices | Lean load generation |
| Socket closed / reset | Errors cap throughput |
Frequently asked questions
Section titled “Frequently asked questions”Does more threads always mean more RPS?
Section titled “Does more threads always mean more RPS?”No. After the server saturates, extra threads mostly increase queueing and response time, not useful throughput.
Why is calculated RPS higher than the dashboard?
Section titled “Why is calculated RPS higher than the dashboard?”Calculators assume stable service time and little think time. Under load, service time rises and timers reduce rate.
Is flat throughput with rising errors a success?
Section titled “Is flat throughput with rising errors a success?”No. Prefer healthy throughput with low error % and controlled percentiles (glossary).
People Also Ask
Why is JMeter throughput lower than my target RPS?
Typical reasons are too few threads for the response time, response time growth under load, heavy listeners, think time, injector saturation, or server throttling. Size threads from measured response time and validate in CLI mode.
Does adding threads always increase JMeter RPS?
No. After the server saturates, extra threads mainly increase queueing and latency rather than useful throughput.
Was this page helpful?
Thanks for the feedback!Tell us what's missing on GitHub