skip to content

A JMeter Constant Throughput Timer targets 600 samples a minute but the run achieves 240 - what does the timer do about it?

level: seniorimportance: should knowfreq 54%

answer

  1. Timers only ever add time
  2. Look at what the delay returns when late
  3. Nothing here creates a thread
  4. The shortfall is completely silent

basics

~20 s

Nothing. A JMeter timer can only add delay, never remove it or add threads, so once it falls behind schedule it simply stops pausing. There is no catch-up burst, no warning and no failed sample.

solid answer

~50 s

A Constant Throughput Timer paces by **inserting a pause before each sampler in its scope**; it cannot make a thread go faster and it cannot start another one. Its `delay()` compares the next scheduled start with the clock: when the clock has already passed that target, the timer moves its schedule to now and returns `0`. So a run that falls behind simply gets zero delay from then on, and the achieved rate is whatever the threads manage, here 240 a minute. Nothing marks the gap. No sample fails, no line appears in `jmeter.log`, and the exit status is unaffected. If 600 a minute is the requirement, the shortfall is in the plan or the system: too few threads in the group, samplers that take too long, or other timers and heavyweight elements in the same scope adding their own time.

code

java · 8 lines
java
long currentTarget = previousTime + calculateDelay();
if (currentTime > currentTarget) {
    // We're behind schedule -- try to catch up:
    previousTime = currentTime; // assume the sample will run immediately
    return 0;
}
previousTime = currentTarget;
return currentTarget - currentTime;

go deeper

for a junior

Remember the one-line rule: a timer can only add a pause. If the run is slower than the target, the timer is already waiting zero and cannot help.

for a middle

Explain the catch-up logic. When the scheduled start is in the past the timer resets its schedule to now and returns zero, so there is no queue of missed slots and no later burst.

for a senior

Work the diagnosis in the plan: thread count, time per sample, and the other timers and elements sharing the scope. Also point out that nothing in the run flags the shortfall by itself.

for a principal

Insist the intended rate and the achieved rate are both reported. A plan whose stated target is quietly unreachable will be read as evidence the system met that load, which is a reporting failure, not a tooling one.

## A timer is a brake, never an engine Every JMeter timer implements one method that returns a number of milliseconds to wait. That is the entire contract. A timer cannot create a thread, shorten a response, or run a sampler out of turn, so the only direction it can move the rate is **down**. The Constant Throughput Timer's own description calls its field a *maximum*, and the manual adds that the throughput will be lower if the server cannot handle it or if other timers and time-consuming elements get in the way. That is why a target of 600 samples a minute is an upper bound. If the plan would produce 240 a minute with no timer at all, adding a timer asking for 600 changes nothing. ## What the timer does when it is already late The timer keeps one field, the time it last decided the next sample should start. On each call it adds the computed gap to that field and compares the result with the clock. - If the target start is still in the future, the timer returns the difference and remembers the target. - If the clock has already gone past it, the timer resets its remembered time to now and returns `0`. Zero is the floor. There is no negative delay, no queue of missed slots, and no burst afterwards to make the average come out right. A run that spends its whole steady state behind schedule is effectively running with the timer disabled. ## Where the missing samples went With 600 a minute asked for and 240 delivered, the gap is not the timer's doing. The candidates, all of which are visible in the plan: 1. **Too few threads.** A group's threads run their scoped samplers one after another, so the number of threads in the group and the time each sample takes together set what the group can start. The timer has no way to add threads. 2. **Samplers that take longer than the gap.** At 600 a minute the timer wants a sample started every 100 ms across whatever it is pacing; a sampler that takes far longer than its share makes that impossible. 3. **Other timers in the same scope.** The manual notes that all timers in a scope are processed before each sampler, so a delay timer sitting alongside adds its pause on top. 4. **Expensive elements in the scope.** Anything that runs per sample and costs real time, on the injector or on the wire, eats into the gap. Which side of the wire the limit sits on, the generator or the system under test, is a performance-testing discipline of its own and not something the timer will tell you. What is JMeter-specific here is simply that the timer stays silent either way. ## What the run does not tell you - No sample is marked failed because of a missed target. - The timer logs nothing when it returns zero. - The process exit status is unaffected by a rate shortfall. If a missed target has to be visible, it has to be made visible outside the timer, by comparing the achieved rate in the results against the number you asked for. ## What to change Raising the target is the one change that certainly does nothing: the timer is already returning zero. The levers that move the achieved rate are the Thread Group's thread count, the work each iteration does, and the other elements sharing the timer's scope. Once the unpaced plan can comfortably exceed 600 a minute, the timer starts doing its job again and holds the rate at the target.

  • Does a Constant Throughput Timer ever return a negative delay to catch up?
    No. It returns the difference between the scheduled start and now only while that start is still in the future. Once the clock has passed it, the timer moves its schedule to the current time and returns zero, so missed slots are dropped rather than repaid by a later burst.
  • Which setting would you look at first when the target is missed?
    The Thread Group's Number of Threads. The timer can only delay threads that already exist, so a group that cannot produce 600 samples a minute unpaced will not produce them paced either. Time per sample and any other timers sharing the scope come next.
  • Would raising the Target Throughput to 1200 help?
    No. The timer is already returning zero delay because it is behind schedule, so a larger target changes nothing about what the threads do. It only makes the plan's stated intent misleading to the next reader.

A Constant Throughput Timer is a metronome, not extra musicians. It can hold the orchestra back to the beat, but if the players cannot reach the tempo, setting the metronome faster changes nothing you can hear.

saying these in an interview costs you the question

  • Expects the timer to fire a catch-up burst
  • Thinks a missed target fails the run
  • Believes raising the target raises the achieved rate
  • Assumes the timer starts extra threads to keep up
  • Looks for a warning the timer never logs