Timers, Think Time, Pacing, Throughput, and Realistic User Behavior: Configuration, Design Patterns, and Trade-Offs
Timer selection is a workload-model decision. Similar average RPS can arise from very different user populations and arrival processes, so the design must state what is being controlled.
Learning objectives
- Choose think time versus pacing.
- Select fixed versus randomized delays.
- Separate closed users from rate schedules.
- Compare Constant and Precise Throughput Timer.
- Compare PTT with optional experimental Open Model.
- Place per-request and scenario-level timing deliberately.
1. Local-only design boundary
http://127.0.0.1:8000,
≤4 threads, ≤12 seconds.
Flexible timer/rate configuration never authorizes a shared or
public target.
2. Think time versus pacing
| Question | Think time | Pacing |
|---|---|---|
| Controls | Pause between user actions. | How often a scenario repeats/starts. |
| Typical component | Constant / Uniform Random Timer. | Throughput timer, scenario wait, arrival model. |
| Should change to hit RPS? | Only if user behavior changed. | Yes if workload frequency requirement changed. |
3. Fixed versus randomized
Fixed waits maximize repeatability; randomized waits reduce artificial synchronization and can better represent heterogeneous users. Randomness remains a configuration input: distribution, bounds, and seed (where supported) belong in evidence.
4. Closed users versus rate schedulers
Classic Thread Group + think time represents a bounded population. A throughput timer constrains sampler departures but still relies on that thread pool. If five agents cannot generate a business target because their real think time is long, that result may be the answer rather than a reason to falsify think time.
5. Constant versus Precise Throughput Timer
| Aspect | Constant Throughput Timer | Precise Throughput Timer |
|---|---|---|
| Schedule | Converges toward target, often more even. | Precomputed randomized Poisson-style departures. |
| Units | Samples/minute. | Samples per throughput period. |
| Threads created | No. | No. |
| Repeatability | Algorithm/state driven. | Non-zero seed repeats schedule. |
| Use here | Simple even-rate comparison. | Randomized scenario-start scheduling. |
6. PTT versus Open Model Thread Group
PTT releases existing threads; Open Model creates scenario arrivals from a schedule. Current docs say Open Model can be a better semantic match for desired load profiles in many cases, but the component is explicitly experimental. Use it only when independent arrivals are central and the exact JMeter version/schedule/seed are pinned.
7. Per-request versus scenario-start placement
A broad Timer can delay Browse and Submit; a Submit child Timer delays only Submit. A PTT intended to schedule scenario starts belongs narrowly under the first scenario element, not at Thread Group scope where it could pace every request.
8. Required concurrency is part of design
Estimate N ≈ λW, round up, add measured headroom, then
verify JTL active threads, target concurrency, sampler percentiles,
generator CPU/JVM/network, and schedule misses. Do not keep adding
threads without identifying the limiting layer.
9. Keep timing separate from infrastructure tuning
| Layer | Examples | Wrong substitution |
|---|---|---|
| JMeter workload | Timer type/scope/rate. | Heap change to “fix” think time. |
| Generator JVM | CPU/heap/GC. | Shorter user waits to hide injector saturation. |
| OS/network | Sockets/DNS/bandwidth. | Calling connection churn pacing. |
| SUT | Service time/queues. | Reducing timers until queues disappear. |
| CI/container | CPU quota/startup. | Assuming identical JMX means identical injector capacity. |
10. Repeatability and seeds
For comparison runs, a non-zero PTT seed can reproduce the same
departure schedule. Multiple same-rate groups should not blindly
reuse the same seed because they can synchronize departures. For
Uniform Random Timer, document the distribution and any global
timer.factor.
11. timer.factor is a workload input
timer.factor multiplies delays from
Uniform/Gaussian/Poisson Random Timers. A hidden value such as 0.1
silently accelerates the workload. If used, make it explicit and
record it; never use it as an undocumented CI shortcut.
Preserve the load JTL with its matching jmeter.log,
timer/rate configuration, and run manifest for every comparison.
12. Decision table
| Requirement | Preferred approach | Evidence |
|---|---|---|
| Exactly 500 ms before Submit | Constant Timer under Submit. | Timeline proves only Submit is delayed. |
| 300–600 ms before Submit | Uniform Random Timer under Submit. | Gap distribution + config. |
| Even ~1 request/s | Constant Throughput Timer. | Configured + achieved label RPS. |
| Random ~1 scenario start/s | PTT under first scenario element. | Schedule/seed + Browse-start RPS. |
| Independent open arrivals | Optional Open Model. | Pinned version + experimental status + arrival evidence. |
| Five fixed human users | Classic Thread Group + behavior Timer. | Achieved rate, not forced rate. |
Knowledge check
Why should scenario-start PTT not normally sit at Thread Group scope?
It could be inherited by every sampler and would pace requests other than the intended scenario-start label.
How do CTT and PTT differ in spacing?
CTT tends toward a more even rate; PTT creates randomized Poisson-style departures.
Can a throughput timer compensate for too few threads?
No. It paces existing thread supply.
Why must timer.factor be recorded?
It can silently multiply random-timer pauses and therefore change the workload.
When is Open Model a better semantic fit?
When independent scenario arrivals are the actual demand mechanism and experimental/version-pinned behavior is acceptable.
Official references and version notes
- Elements of a Test Plan — timer scope, additive delays, execution order, and Thread Groups.
- Component Reference — Constant, Uniform Random, Constant Throughput, Precise Throughput, and Open Model behavior.
- Properties Reference — timer.factor and result settings.
- Best Practices — thread sizing, coordinated-omission warning, CLI execution, and lean listeners.
- Getting Started — GUI authoring versus CLI load execution.
- Download Apache JMeter — current production release and Java requirement.
Verified 2026-09-05: Apache JMeter 5.6.3; release requires Java 8+, labs use Java 17; no plugins. Timers run before in-scope samplers and applicable timers add together. Constant/Precise Throughput Timers pace existing threads and cannot guarantee configured throughput if threads, other delays, the generator, or target are limiting. Precise Throughput Timer uses a Poisson-style schedule, and its timer test-duration field is not the Thread Group stop condition. The current Open Model Thread Group is explicitly experimental and is optional only in this chapter.
Keep the academy open
Support free, practical DevOps education.
Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0
Send only Ethereum/ERC-20 compatible assets to this
address.