What Is a Thread Group?

Where the term comes from

Thread group is Apache JMeter vocabulary, and it is the most widely recognised name for the concept because JMeter dominated load testing for well over a decade. In JMeter a test plan contains one or more thread groups, and every thread inside a group simulates one user running the samplers beneath it.

The name is literal. Each simulated user really is an operating-system thread, which is also the model’s central limitation: threads cost megabytes of stack apiece, so a single JMeter machine typically tops out in the low thousands of users and larger tests need a cluster of load generators.

What thread groups map to in modern tools

Tools built after JMeter mostly abandoned the thread abstraction, because coroutines and async I/O simulate a waiting user far more cheaply than a blocked OS thread does. What survived is the structure, under different names.

• The request sequence in a thread group is now usually a scenario.
• The thread count is now a virtual user count, backed by a coroutine rather than a thread.
• The ramp-up period kept its name almost everywhere — see ramp-up.
• The loop count is usually replaced by a duration, since holding a shape for a fixed time is easier to reason about than a fixed iteration count.

Why the vocabulary still matters

Most teams migrating off JMeter arrive with existing test plans described in thread groups, and the translation is not always one-to-one. A plan with three thread groups of 100, 50, and 50 threads is describing a traffic mix, and the modern equivalent is one VU pool split across three scenarios by weight, not three separate tests.

The distinction matters because weighted mixes and fixed per-group counts behave differently at the edges. A weighted mix keeps the ratio steady as the pool grows or shrinks; fixed counts do not.