Thread Groups

Analogy categoryAnalogies

What a Thread Group Represents

A Thread Group is JMeter's basic unit of concurrency: each 'thread' is one virtual user that executes the samplers nested beneath the Thread Group independently of every other thread. 'Number of Threads' sets how many virtual users exist, 'Ramp-Up Period' sets how many seconds JMeter takes to start all of them (so 50 threads with a 10-second ramp-up start roughly one every 0.2 seconds), and 'Loop Count' sets how many times each thread repeats the full sequence of samplers before finishing, with an 'Infinite' checkbox available when a Duration-based run is preferred instead.

🏏

Cricket analogy: Like a franchise fielding several batting pairs at different nets simultaneously, each pair batting through their own set of throw-downs independently, a Thread Group's threads each run through the same samplers independently of one another.

Why Ramp-Up Strategy Matters

Setting Ramp-Up too low relative to the thread count creates an instantaneous spike — 500 threads starting in 1 second — which tests a very different failure mode (connection-storm behavior) than the gradual growth real traffic usually shows; a longer ramp-up, such as 500 threads over 300 seconds, more realistically models organic traffic building toward a peak and makes it easier to correlate a specific point in time with the moment response times start to degrade. As a rule of thumb, testers often set the ramp-up so that roughly one thread starts per second, adjusting up or down depending on whether the goal is to test gradual growth or a sudden burst.

🏏

Cricket analogy: Like the difference between a T20 chase's frantic final over versus a Test match's steady accumulation of runs over a full session, a short ramp-up spikes load suddenly while a long ramp-up builds it gradually like a patient innings.

bash

# Override Thread Group properties from the command line without editing the .jmx
jmeter -n -t CheckoutTest.jmx \
  -Jthreads=500 \
  -Jrampup=300 \
  -Jloops=10 \
  -l results.jtl

# Inside the .jmx, the Thread Group fields reference these as:
# Number of Threads:  ${__P(threads,50)}
# Ramp-Up Period(s):  ${__P(rampup,60)}
# Loop Count:         ${__P(loops,1)}

Beyond the Standard Thread Group

The built-in Thread Group only supports a linear ramp-up followed by a flat plateau. For more realistic load shapes — a slow ramp, a steady soak, a second spike, then a ramp-down — testers install the jpgc-casutg plugin (via the Plugins Manager) to get the Ultimate Thread Group, which defines load as a table of rows (start threads, initial delay, startup time, hold time, shutdown time), or the Stepping Thread Group, which adds a fixed number of users every fixed interval to model gradual staircase growth rather than one continuous ramp.

🏏

Cricket analogy: Like a bowling attack rotating through pace, then spin, then pace again across a session rather than one bowler sending down every over, the Ultimate Thread Group lets you shape load in stages instead of one flat ramp.

The 'Scheduler' checkbox on a standard Thread Group unlocks 'Duration' (seconds to keep running after ramp-up completes) and 'Startup Delay' (seconds to wait before the ramp-up itself begins), which together let you run a fixed-length soak test without manually stopping JMeter or calculating an exact loop count.

Thread Group Behavior on Sampler Errors

The 'Action to be taken after a Sampler error' setting controls what a thread does when one of its samplers fails: 'Continue' moves on to the next sampler regardless (the default, best for realistic user simulation where one failed page load doesn't end the whole session), 'Start Next Thread Loop' abandons the rest of the current loop's samplers but starts the next loop iteration, 'Stop Thread' ends just that one virtual user's execution, and 'Stop Test' (or 'Stop Test Now', which is more abrupt) halts the entire run — useful for smoke tests where any single failure means there's no point continuing.

🏏

Cricket analogy: Like a batsman who gets beaten by one delivery but still faces the next ball rather than walking off, 'Continue' lets a thread keep going after one failed sampler, mirroring how a real user shrugs off one broken page load.

A Thread Group's threads are independent virtual users, each executing the same nested samplers on its own.
Number of Threads, Ramp-Up Period, and Loop Count together define user count, startup pacing, and repetitions.
A short ramp-up simulates a sudden traffic spike; a long ramp-up simulates gradual, organic traffic growth.
The Scheduler checkbox adds Duration and Startup Delay for time-bound soak tests instead of loop-count-bound tests.
Plugins like the Ultimate Thread Group and Stepping Thread Group support complex, multi-phase load shapes the built-in Thread Group cannot.
'Action to be taken after a Sampler error' controls whether a thread continues, restarts its loop, stops itself, or stops the whole test.
'Continue' is the default and most realistic option, since one failed request rarely ends a real user's whole session.