Timers, Think Time, Pacing, Throughput, and Realistic User Behavior: Diagnostics, Failure Modes, and Production Practices

1. Preserve evidence first

2. Diagnostic sequence

flowchart TD
E[Preserve evidence] --> V[Versions]
V --> C[Users + duration + all timers]
C --> S[Walk Timer scope]
S --> M[Sum waits + compute N≈λW]
M --> A[Configured vs achieved rate]
A --> G[Generator CPU/JVM/network]
G --> T[Target latency/queues]
T --> F[Smallest correction]
F --> R[Bounded rerun]

3. Failure: arbitrary stabilization sleeps

Adding a 30-second Timer because an environment sometimes is not ready changes the workload and hides readiness. Use a bounded preflight/readiness check before load; keep business think time only where the user model requires it.

4. Failure: assuming a throughput timer creates threads

A PTT can schedule 3 starts/s while one thread can complete only ~1.67 scenarios/s. The rate miss is initially a thread-supply problem, not proof the server lacks capacity.

5. Intentionally broken broad scope

Thread Group
├── Constant Timer — 400 ms
├── Browse
└── Submit

The Timer applies before Browse and Submit. If the business rule is “think after Browse,” move it under Submit and preserve before/after timelines.

6. Double-counted think time

Thread Group
├── Constant Timer — 300 ms
├── Browse
└── Submit
    └── Uniform Random Timer — offset 300 ms, max 300 ms

Submit waits about 600–900 ms because both Timers apply; Browse waits 300 ms. If the intended Submit pause was 300–600 ms, the broad Timer is a modeling defect.

7. Rate above generator/target capacity

Do not repeatedly add threads until the number matches. Attribute the limit first and remain inside the authorized envelope.

8. Delayed completion is not endpoint latency

80 ms Browse + 400 ms think + 120 ms Submit yields roughly 600 ms journey time, but the target sampler latencies remain around 80 and 120 ms. Report journey duration and endpoint latency as different populations.

9. PTT Test duration is not a stop condition

The PTT Test duration field helps schedule generation. A Thread Group with infinite loops still needs an independent finite lifetime/stop condition.

10. Start no pauses / validation can bypass Timers

JMeter provides Start no pauses, and validation mode normally ignores Timers. These are authoring tools, not paced-load evidence. Record the execution mode before changing a Timer because “there were no waits.”

11. Experimental Open Model drift

If an optional Open Model schedule is used, preserve exact JMeter version, schedule, seed, and experimental status. Current semantics evaluate the schedule at test start and can interrupt active scenarios when it ends unless tail pause is provided.

12. Shortcuts to reject

• No arbitrary long sleeps, blanket retries, or unbounded thread increases.
• No giant heap/OS tuning without generator evidence.
• No global property hacks or timer.factor changes hidden from the manifest.
• No TLS/RMI verification disablement or public targets.
• No evidence deletion after a successful rerun.

Knowledge check

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.