skip to content

In JMeter's Thread Group, what do the Number of Threads and Ramp-up period fields set?

level: juniorimportance: must knowfreq 86%

answer

  1. Two boxes at the top of the panel
  2. One counts walkers, one spreads their starts
  3. Divide the window by the count
  4. The first thread never waits

basics

~20 s

Number of Threads sets how many JMeter threads run the plan concurrently. Ramp-up period sets how many seconds JMeter takes to start all of them. Each thread then walks the whole plan on its own.

solid answer

~40 s

`Number of Threads (users):` is the count of JMeter threads the group starts, and each thread executes the entire subtree under the group independently, repeating it according to `Loop Count`. `Ramp-up period (seconds):` is the window those starts are spread over: JMeter divides the ramp by the thread count to get one fixed slot, starts the first thread immediately, and delays each later thread by one more slot. With 200 threads and a 300-second ramp the slot is 1.5 seconds, so the 200th thread begins around 298.5 seconds in — the last start lands one slot short of the window, not on it. A fresh Thread Group in JMeter 6.0.0 opens with both fields set to 1. A ramp-up of 0 collapses the slot to zero and every thread starts at once.

code

text · 9 lines
text
Thread Properties
  Number of Threads (users): 200
  Ramp-up period (seconds):  300
  Loop Count:                Infinite

slot          = 300 s / 200 threads = 1.5 s
thread 1   -> starts at   0.0 s
thread 2   -> starts at   1.5 s
thread 200 -> starts at 199 * 1.5 = 298.5 s

go deeper

for a junior

Recall the two labels and what each unit means: threads are simulated users, ramp-up is seconds. Be able to say that ten threads over a hundred seconds means roughly one new thread every ten seconds.

for a middle

Explain the slot arithmetic out loud: ramp divided by thread count, first thread at zero, last thread one slot short of the window. Mention that both fields default to 1 in a new group.

for a senior

Show that you read the ramp as a start schedule rather than run time, and that you check whether the group is actually at full concurrency for the part of the run you intend to report on.

for a principal

Own the convention for how ramps are expressed across the team's plans, so that two runs of the same plan are comparable and nobody is quietly reading numbers gathered while threads were still arriving.

## The two fields The stock **Thread Group** panel opens with a box titled `Thread Properties` whose first two entries are `Number of Threads (users):` and `Ramp-up period (seconds):`. In a saved plan they are stored as `ThreadGroup.num_threads` and `ThreadGroup.ramp_time`. A Thread Group created fresh in JMeter 6.0.0 comes up with **both set to 1** and `Loop Count` set to 1, so an untouched group runs the plan exactly once on one thread. **Number of Threads** is a count of JMeter threads. Each one is a real JVM thread that walks the whole subtree beneath the group, top to bottom, on its own, and repeats that walk according to `Loop Count`. Threads do not cooperate: each carries its own JMeter variables and its own iteration counter, and each is named after the group, so a listener shows entries such as `Checkout 1-37` for thread 37 of the group named `Checkout`. **Ramp-up period** is the number of seconds JMeter takes to get every thread of that group started. It is not extra run time bolted onto the end, and it is not that whole period served as a pause by every thread before its first request — each thread waits its own growing slice of it, and the first waits none. It is only the spacing of the starts. ## How JMeter spaces the starts In the default startup mode JMeter computes one fixed slot for the whole group and hands each thread a growing initial delay: 1. `slot = ramp-up seconds x 1000 / number of threads`, rounded to whole milliseconds; 2. the first thread is given an initial delay of `0` and starts immediately; 3. thread *k* is given an initial delay of `(k - 1) x slot`; 4. every thread object is created up front and simply sleeps its delay before its first iteration. Two consequences of that arithmetic come up constantly in interviews: - **The first thread never waits.** With a single thread the ramp-up is effectively zero however large the field is. - **The last start lands one slot short of the window.** For *n* threads the final start is at `ramp x (n - 1) / n`, not at `ramp`. JMeter's own manual spells this out: with 10 threads and a 100-second ramp, the tenth thread starts after 90 seconds, not 100. Setting the field to `0` makes the slot zero, so all threads start together — the usual way to express an instantaneous arrival of the whole population in the stock group. ## Worked example: 200 users over five minutes `Number of Threads (users): 200` with `Ramp-up period (seconds): 300` gives a slot of `300000 / 200 = 1500 ms`: | thread | initial delay | starts at | |---|---|---| | 1 | 0 ms | 0.0 s | | 2 | 1500 ms | 1.5 s | | 100 | 148500 ms | 148.5 s | | 200 | 298500 ms | 298.5 s | The group is at full concurrency shortly before the five-minute mark and stays there until something stops the threads — `Loop Count` running out, the scheduler's `Duration` expiring, or the run being stopped by hand. ## What a thread does once it has started A started thread runs the group's samplers in order, waits for each response before moving to the next element, and honours any timers in scope. When it reaches the end of the subtree it counts one iteration and, if `Loop Count` allows, starts again from the top. Nothing in these two fields tells JMeter how fast to send; they tell it **how many** walkers there are and **when each one sets off**. ## Defaults and edge cases worth remembering - Both fields accept a plain integer; the panel's other load controls (`Loop Count`, `Specify Thread lifetime`) are separate settings and do not feed into the slot arithmetic. - `Ramp-up period` of `0` is legal and means a simultaneous start. - Ramp-up is per Thread Group. Two groups in the same plan ramp independently and, by default, at the same time. - The ramp-up window is consumed by the group's own clock, so if you also enable the scheduler, the ramp happens **inside** `Duration` rather than before it. - While threads are still being started JMeter polls for a shutdown request at an interval governed by the `jmeterthread.rampup.granularity` property, which defaults to 1000 ms — that is why stopping a long ramp is not instantaneous.

  • In a JMeter Thread Group with 10 threads and a Ramp-up period of 100 seconds, when does the tenth thread start?
    At about 90 seconds. JMeter divides the ramp by the thread count to get a 10-second slot, gives the first thread a delay of zero, and gives thread *k* a delay of `(k - 1)` slots — so the tenth start is nine slots in. The manual states this example explicitly.
  • What does a Ramp-up period of 0 do in a JMeter Thread Group?
    It makes the per-thread slot zero, so every thread is given an initial delay of `0` and all of them start together. That is how the stock group expresses an instantaneous arrival of the whole population; nothing rejects the value.
  • Do two Thread Groups in the same JMeter plan share one ramp-up?
    No. `Ramp-up period` is a property of each Thread Group, so each group ramps its own threads on its own clock. By default the groups also start at the same moment, so their ramps overlap unless one is offset by the scheduler's `Startup delay`.

saying these in an interview costs you the question

  • Says the ramp-up period is how long the test runs.
  • Treats Number of Threads as a requests-per-second setting.
  • Insists the last thread starts exactly at the end of the ramp-up window.
  • Confuses Ramp-up period with the scheduler's Startup delay field.
  • Thinks a ramp-up of zero is rejected as invalid.