skip to content

In JMeter's stock Thread Group, which field sets the request rate?

level: middleimportance: must knowfreq 68%

answer

  1. Count the boxes on the panel
  2. Every field is a count or a duration
  3. A thread blocks until its response arrives
  4. Rate is named in a timer instead

basics

~20 s

None of them. The stock Thread Group has no throughput field: Number of Threads caps how many threads run at once, and the rate the plan achieves is a result of the run rather than a setting.

solid answer

~40 s

The stock Thread Group's load controls are `Number of Threads (users):`, `Ramp-up period (seconds):`, `Loop Count`, and — behind the `Specify Thread lifetime` checkbox — `Duration (seconds):` and `Startup delay (seconds):`. **None of them is a rate.** A JMeter thread is strictly serial: it serves any timers in scope, sends a sampler, waits for the response, and only then moves on, so raising `Number of Threads` raises the ceiling on concurrency, not the number of requests per second. If a plan must express arrivals per second instead, JMeter has separate elements for that — the `Constant Throughput Timer` and `Precise Throughput Timer` in the timer family, and the `Open Model Thread Group`, whose schedule is written as rates. Choosing between concurrency-shaped and arrival-shaped load is workload-modelling theory and sits outside the Thread Group panel.

go deeper

for a junior

Learn the five load fields by name and notice that each is a count or a number of seconds. If someone asks you to set a requests-per-second figure on the Thread Group, the honest answer is that the panel has no such box.

for a middle

Explain the blocking thread loop: serve timers, send, wait for the response, repeat. That is the mechanism that turns Number of Threads into a concurrency ceiling instead of a send rate.

for a senior

Demonstrate that you report the achieved rate as a measured outcome next to the thread count, and that you notice when a slower system quietly changes what a fixed thread count actually applied.

for a principal

Own the decision of whether the team's plans are written in concurrency or in arrivals, and make sure requirements handed to the test team are stated in terms the chosen JMeter element can actually express.

## What the panel actually offers Open a stock **Thread Group** in JMeter 6.0.0 and every load-shaping control on it is one of these: | field | stored as | what it fixes | |---|---|---| | `Number of Threads (users):` | `ThreadGroup.num_threads` | how many threads run the plan at once | | `Ramp-up period (seconds):` | `ThreadGroup.ramp_time` | over how many seconds those threads start | | `Loop Count` | the nested Loop Controller's `LoopController.loops` | how many times each thread repeats the plan | | `Duration (seconds):` | `ThreadGroup.duration` | how long the group is allowed to run | | `Startup delay (seconds):` | `ThreadGroup.delay` | how long before the group starts | There is no sixth field, and in particular there is no requests-per-second, transactions-per-second or throughput box. Saying so plainly is the answer the question is looking for; candidates who hunt for a hidden setting usually invent one. ## Why a thread count is not a rate A JMeter thread is a plain sequential program: 1. it serves any timers in scope of the sampler it is about to run; 2. it runs that sampler and blocks until the response comes back or times out; 3. it hands the result to the post-processors, assertions and listeners; 4. it moves to the next element, or counts an iteration and starts again from the top. Because step 2 blocks, a thread cannot have two requests outstanding, and it cannot start its next request early because the plan is behind. `Number of Threads` therefore caps **concurrency** — the number of requests that can be in flight at once — and the rate the run achieves is whatever that population of serial walkers happens to produce. Change nothing in the plan, make the server slower, and JMeter will send fewer requests per second without any field changing value. The corollary that trips people up: doubling `Number of Threads` does not reliably double throughput, and reading the achieved rate off a listener does not tell you the group was asked for that rate. The rate was never requested. ## Where JMeter does let you name a rate JMeter has three real answers when a plan must be expressed as arrivals rather than concurrency, and none of them is a Thread Group field: - the **Constant Throughput Timer**, which delays samplers to hold a target sample rate; - the **Precise Throughput Timer**, which schedules sample times from a target rate; - the **Open Model Thread Group**, a separate group type whose `Schedule` is written directly as rates. Third-party plugin groups exist as well, and are not part of the Apache download. The mechanics of each of these belong with those elements; from the stock Thread Group's point of view the only thing to know is that they are where a rate is spelled out. ## Worked example: 200 users, a five-minute ramp, one hour A plan configured with `Number of Threads (users): 200`, `Ramp-up period (seconds): 300`, `Loop Count: Infinite`, `Specify Thread lifetime` ticked and `Duration (seconds): 3600` promises exactly this: at most 200 concurrent walkers, arriving over five minutes, stopping an hour after the group started. It promises nothing about requests per second. If each iteration averages half a second the run will produce a very different rate than if it averages five seconds, and the panel will look identical in both cases. That is why a JMeter run report needs the achieved rate reported alongside the thread count: the two are independent facts about the run, and only the thread count was chosen. ## Common mistakes - **Quoting the thread count as the load level.** "We ran 200 users" fixes the concurrency ceiling, not the traffic. - **Assuming ramp-up is a rate.** `Ramp-up period` schedules thread starts once; it does not govern requests after they are up. - **Assuming the scheduler's `Duration` throttles anything.** It only stops threads at a wall-clock deadline. - **Inventing a field.** There is no throughput setting on the stock Thread Group panel, so a candidate who names one is guessing. - **Reaching for the plugin thread groups without saying they are third party.** The Apache download ships the stock group and the Open Model Thread Group; the `jpgc` custom thread groups are an add-on.

  • If the stock Thread Group has no rate field, which JMeter elements do express a target rate?
    Three: the `Constant Throughput Timer` and the `Precise Throughput Timer`, which pace samplers toward a target sample rate, and the `Open Model Thread Group`, a separate group type whose `Schedule` is written as rates. Third-party `jpgc` thread groups add more, but they are not part of the Apache download.
  • Your JMeter run with 200 threads produced far fewer requests per second than the last run of the same plan. Does that mean the plan changed?
    Not necessarily. `Number of Threads` fixes only the concurrency ceiling; each thread waits for its response before sending again, so the achieved rate moves with response time. Compare the two runs' response times before assuming the plan or its configuration differs.

saying these in an interview costs you the question

  • Names a throughput or requests-per-second field on the Thread Group panel.
  • Claims doubling Number of Threads reliably doubles requests per second.
  • Says Ramp-up period sets how fast requests are sent.
  • Treats the scheduler's Duration as a throttle on the applied load.
  • Presents the plugin Concurrency Thread Group as part of the Apache download.