A JMeter Thread Group ramps 200 threads over 300 seconds with Duration 3600. How long does the last thread sample?
answer
- The clock starts before full concurrency
- Every thread stops at the same instant
- Subtract the ramp from the hour
- Duration equals ramp plus intended hold
basics
~20 sAbout 3,300 seconds. JMeter measures the scheduler's Duration from the group's start, so the five-minute ramp is spent inside the hour and the last thread, starting near 298.5 seconds, stops when all the others do.
solid answer
~50 sThe group's scheduled end is derived from when the group starts, not from when it reaches full concurrency. With `Ramp-up period (seconds): 300` and `Duration (seconds): 3600`, every thread stops at roughly the same wall-clock instant — about an hour after the group began — so the first thread samples for close to 3600 seconds and the 200th, which started at about 298.5 seconds, samples for about 3300. The whole group therefore occupies about an hour of wall clock, not an hour plus a ramp. If you need a full hour at 200 threads, set `Duration` to the ramp plus the intended hold, for example `3900`. Two further wrinkles: the end is only observed **between samples**, so an in-flight request is never interrupted, and with the scheduler on JMeter stops a thread rather than serving a timer pause that would end past the deadline.
code
text · 8 linesRamp-up period (seconds): 300 Duration (seconds): 3600
t=0.0 s thread 1 starts group end time fixed at t=3600 s
t=298.5 s thread 200 starts (200 concurrent from here)
t=3600 s all threads stop thread 200 sampled ~3301 s
For a full hour at 200 threads instead:
Duration (seconds): 3900 (300 ramp + 3600 hold)go deeper
Recall that the scheduler's Duration is measured from when the group starts, so a ramp happens inside it. An hour of Duration is an hour of wall clock, not an hour after the threads are all up.
Do the arithmetic out loud: last start at ramp times (n-1)/n, common stop at the group's start plus Duration, so the last thread samples for Duration minus its start offset. Set Duration to ramp plus hold when a full hold is wanted.
Spot the consequence in someone else's results: minutes of the scheduled window were collected while threads were still arriving, and a run reported as an hour at 200 users held 200 users for less than that.
Fix the convention rather than the run: agree how the team expresses hold time versus total duration in plans, so two teams quoting an hour at 200 users mean the same thing.
## How JMeter computes the group's end With `Specify Thread lifetime` ticked, JMeter turns the two scheduler fields into a start time and an end time per thread: - **start time** = now + `Startup delay (seconds):` - **end time** = that start time + `Duration (seconds):` The key word is *now*: the clock starts when the group starts, before any thread has served a request. The ramp-up is not added on top — it is spent inside `Duration`. Both of the group's startup modes land on the same wall clock, by slightly different routes. In the default mode every thread object is created up front and given its own start and end times from an essentially identical *now*. With `Delay Thread creation until needed` ticked, a single starter thread computes one end time after the startup delay and stamps every thread it creates with that same value, and it stops creating threads at all once the end time has passed. ## The arithmetic for 200 threads over five minutes The slot is `300 s / 200 = 1.5 s`, so with `Duration (seconds): 3600`: | thread | starts at | stops at | actually sampling | |---|---|---|---| | 1 | 0.0 s | ~3600 s | ~3600 s | | 100 | 148.5 s | ~3600 s | ~3451 s | | 200 | 298.5 s | ~3600 s | ~3301 s | The group is at 200 concurrent threads only from about 298.5 s to about 3600 s — roughly 55 minutes of the hour, not 60. Ask for a full hour at full concurrency and the setting is `Duration = ramp + hold`, here `300 + 3600 = 3900`. ## The mirror-image mistake The other half of the confusion runs the opposite way: people budget an hour and five minutes of wall clock for the run and are surprised when it finishes at the hour mark. It finishes at the hour mark because `Duration` began at the group's start. If several groups are staggered with `Startup delay (seconds):`, each group's own hour begins after its own delay, so the plan's total wall clock is the last group's delay plus its duration, not the sum of the durations. ## Where the last start actually lands The two startup modes also differ, slightly, on when the final thread starts: - **default mode** — one fixed slot of `ramp / threads` is applied cumulatively, so the last of 200 threads starts at `199 x 1.5 = 298.5 s`, one slot short of the window; - **`Delay Thread creation until needed`** — the starter recomputes the pause as the remaining ramp divided by the remaining threads before each start, so the last thread starts at about the full `300 s`. The difference is a slot wide and rarely matters on its own, but it does mean the two modes are not byte-identical schedules, and only the second one avoids holding every thread object in existence for the whole run. ## Why the run can still overrun The end time is evaluated **between samples**. JMeter does not interrupt a sampler that is already waiting for a response, so a group whose deadline passed while a slow request was in flight keeps that thread alive until the response or the sampler's own timeout arrives; the manual says the end time may be delayed arbitrarily for exactly this reason. The complementary behaviour, also from the scheduler, is that a timer pause which would finish after the deadline is not served at all — JMeter ends the thread instead of sleeping past the scheduled end. ## Checklist for reading someone else's scheduled group 1. Is `Specify Thread lifetime` ticked at all? 2. Is `Loop Count` set to `Infinite`, so the scheduler is the limit that governs? 3. Does `Duration` include the ramp, and was that intended? 4. Is there a `Startup delay`, and does the reported run window account for it? 5. Do the results cover the whole `Duration`, including the minutes while threads were still arriving? That last point is where the JMeter arithmetic hands off to workload-modelling judgment about which window is worth reporting, which is a separate discipline from the fields on this panel.
- Does ticking Delay Thread creation until needed change when the last thread starts?Slightly. The starter recomputes each pause as the remaining ramp divided by the remaining threads, so the last of 200 threads starts at about the full 300 seconds instead of 298.5. The group's end time is unchanged, so that thread simply samples one slot less.
- What happens to a JMeter sampler still waiting for a response when the Thread Group's Duration expires?Nothing interrupts it. JMeter checks the scheduled end only between samples, so the thread finishes the in-flight request — or waits for its timeout — and stops afterwards. The manual notes the end time may be delayed arbitrarily as a result.
- Two JMeter Thread Groups each have Duration 3600 and the second has Startup delay 600. How long is the plan?About 4200 seconds, not 7200. The delay shifts the second group's own hour later rather than queueing it behind the first, so the plan ends when the last group's start plus its `Duration` is reached — 600 + 3600 here.
saying these in an interview costs you the question
- Says the run lasts the ramp-up plus the Duration.
- Thinks each thread gets its own full Duration from its own start.
- Claims JMeter aborts in-flight samplers the moment Duration expires.
- Assumes the group is at full concurrency for the whole scheduled hour.
- Adds Startup delay to Duration when predicting the group's run length.