A JMeter test without timers is like a car with the accelerator taped to the floor. Your virtual users will fire requests as fast as the server can respond -- no pauses, no think time, no realistic behavior. Real users read pages, fill forms, hesitate before clicking "Place Order". Timers simulate that human behavior. Skip them, and you are not load testing -- you are DDoS-ing your own server.
Timers execute BEFORE each sampler in their scope. If a timer is under a Thread Group, it runs before every sampler in that group. If it is under a specific sampler, it runs only before that sampler. Important: timers delay the START of the next sampler, not the end of the previous one.
The Constant Timer adds a fixed delay before each sampler. Set it to 3000ms and every request waits exactly 3 seconds. It is simple but unrealistic -- real users do not pause for exactly 3.000 seconds every time. Use it for debugging or when you need deterministic timing.
# Add: Right-click Thread Group → Timer → Constant Timer
Thread Delay (in milliseconds): 3000
# Every sampler in this Thread Group will wait exactly 3 seconds before executing.
# 10 requests × 3 second delay = at least 30 seconds of think time per loop.The Uniform Random Timer adds a random delay between a minimum and maximum value. Each request gets a different delay, randomly chosen from a flat (uniform) distribution. It is like rolling a die -- every value in the range is equally likely.
# Add: Right-click Thread Group → Timer → Uniform Random Timer
Random Delay Maximum (ms): 3000
Constant Delay Offset (ms): 1000
# Total delay = Random(0, 3000) + 1000
# So each request waits between 1000ms (1 sec) and 4000ms (4 sec)
# Average delay: 2500msThis is the timer I recommend for most load tests. It uses a Gaussian (bell curve) distribution -- most delays cluster around the mean, with occasional shorter or longer pauses. This is how real humans behave. Most people take about 3 seconds between clicks, but some are faster (1 second) and some are slower (6 seconds, probably reading the page carefully).
# Add: Right-click Thread Group → Timer → Gaussian Random Timer
Deviation (ms): 1000
Constant Delay Offset (ms): 3000
# This creates a bell curve centered at 3000ms with deviation of 1000ms.
# Most delays will be between 2000ms and 4000ms (one standard deviation).
# ~68% of delays: 2000-4000ms
# ~95% of delays: 1000-5000ms
# ~99.7% of delays: 0-6000ms (JMeter caps at 0, no negative delays)Here is where timers get powerful. The Constant Throughput Timer does not add a fixed delay. Instead, it adjusts delays dynamically to achieve a target throughput (requests per minute). If the server is fast, delays are longer. If the server is slow, delays are shorter. You are not saying "wait 3 seconds" -- you are saying "send exactly 60 requests per minute from this thread".
# Add: Right-click Thread Group → Timer → Constant Throughput Timer
Target throughput (samples per minute): 60.0
Calculate Throughput based on:
○ this thread only -- 60 req/min per thread (total = 60 × threads)
○ all active threads -- 60 req/min total across ALL threads
○ all active threads in current thread group -- most common choice
○ all active threads (shared) -- synchronized across groups
○ this thread group only -- 60 req/min for this group combined
# Example: 10 threads, "all active threads in current thread group"
# Total throughput = 60 requests per minute (6 req/min per thread)
# Example: 10 threads, "this thread only"
# Total throughput = 60 × 10 = 600 requests per minuteThe Constant Throughput Timer can only slow things down, not speed them up. If your target is 600 requests per minute but you only have 5 threads and each request takes 2 seconds, the maximum throughput is 150 req/min (5 threads / 2 seconds × 60). You need enough threads to achieve your target rate. Also, it only works accurately over longer durations -- in the first few seconds it is still calibrating.
The Precise Throughput Timer (added in JMeter 5.0) solves the limitations of the Constant Throughput Timer. It delivers exact throughput from the very first second, distributes requests evenly across threads, and handles ramp-up scenarios correctly. Think of the Constant Throughput Timer as an old thermostat that overshoots and oscillates. The Precise Throughput Timer is a modern smart thermostat -- it gets the temperature right immediately.
| Feature | Constant Throughput Timer | Precise Throughput Timer |
|---|---|---|
| Accuracy at start | Inaccurate during ramp-up | Accurate from second 1 |
| Distribution | Random spacing between requests | Evenly distributed (Poisson arrival) |
| Small sample sizes | Inaccurate with few threads | Accurate even with 1-2 threads |
| Configuration | Simple: target per minute | More options: per-period, batch size |
| When to use | Long-running steady-state tests | Any test where throughput precision matters |
| JMeter version | All versions | 5.0+ |
Where you place timers changes their behavior. Here is a pattern I use in every project: a Gaussian timer at the Thread Group level for general think time, plus specific Constant Timers under requests that need different delays.
Thread Group (100 users)
├── Gaussian Random Timer (3000ms ± 1000ms) ← applies to ALL requests
├── Login Request
│ └── Constant Timer (500ms) ← ALSO applies, so total = 500 + Gaussian
├── Browse Products Request
├── Product Details Request
│ └── Constant Timer (5000ms) ← simulates reading product page
├── Add to Cart Request
└── Checkout Request
# CAUTION: When multiple timers are in scope for a sampler, ALL of them apply.
# Login Request gets: Gaussian(3000±1000) + Constant(500) = ~3500ms total
# Product Details gets: Gaussian(3000±1000) + Constant(5000) = ~8000ms total
# Browse Products gets: Gaussian(3000±1000) only = ~3000msWhen multiple timers apply to the same sampler, they ADD together. This catches many people off guard. If you want a single timer per request, place each timer directly under its specific sampler, not at the Thread Group level.
Q: What think time strategy do you use in your performance tests, and why does it matter?
A: I use Gaussian Random Timers as the primary think time because they model real user behavior -- most users pause for a similar duration but with natural variation. I typically set the constant delay to the average think time from production analytics (usually 3-5 seconds for web apps) and the deviation to about 30% of that value. For throughput-controlled tests where the SLA specifies a target request rate, I use the Precise Throughput Timer instead. Think time is critical because without it, you are measuring maximum server throughput under artificial conditions. With realistic think time, you measure how the server performs under realistic concurrent load, which gives you accurate capacity numbers for production planning.
Key Point: Timers are non-negotiable for realistic tests. Use Gaussian Random for human behavior, Constant Throughput or Precise Throughput for rate control. Multiple timers in scope are additive. Place them carefully.
Key Point: Gaussian Random Timer for realistic behavior, Constant/Precise Throughput Timer for rate control. Timers are additive when in scope. No timers = DDoS, not a load test.