JMeter’s "Constant Throughput Timer" is actually a misnomer; it doesn’t guarantee a constant rate, but rather a target rate per minute, and it does so by introducing variable delays.
Let’s see it in action. Imagine we want to hit 60 requests per minute (RPS) with a single thread.
// JMeter Test Plan
// Thread Group:
// Number of Threads: 1
// Ramp-up Period: 1
// Loop Count: Infinite
// Scheduler: Checked
// Duration: 300 seconds
// Startup delay: 0 seconds
// Sampler:
// HTTP Request:
// Server Name or IP Address: example.com
// Path: /
// Timer:
// Constant Throughput Timer:
// Target Throughput: 60
// Calculate Throughput based on: All active threads in all sessions
// Constant Timer: (optional, for realistic pacing)
// Thread Delay (ms): 500
When you run this, you’ll notice the actual RPS fluctuates. If your requests are very fast, the Constant Throughput Timer will inject significant delays to avoid exceeding 60 requests per minute. If your requests are slow, it might not be able to reach 60 RPS.
The core problem JMeter’s Constant Throughput Timer solves is controlling the rate of requests from a load test. Without it, a simple loop with a sampler would just run as fast as possible, quickly overwhelming the system under test and producing unrealistic load patterns. The timer aims to simulate a steady stream of users interacting with an application at a predictable pace.
Internally, the Constant Throughput Timer works by measuring the time taken for the previous batch of requests (within a one-minute window) and calculating the necessary delay to hit the target throughput. It divides the total time available in a minute (60,000 milliseconds) by the target throughput. For example, if the target is 60 RPS, the ideal spacing between requests is 1000ms (60,000ms / 60 RPS). If a request finishes in 200ms, the timer will add a 800ms delay. If it finishes in 1500ms, it will add no delay and potentially miss the target for that minute.
The key lever you control is the "Target Throughput" value. This is the number of samples (requests) JMeter should aim to execute within a one-minute period. The "Calculate Throughput based on" setting is also crucial:
- All active threads in all sessions: This is the most common and generally recommended setting. It calculates the target rate based on the total number of requests across all threads and test runs.
- All active threads in each new session: This calculates the target rate independently for each thread. If you have 10 threads and a target of 60, each thread would aim for 60 RPS, leading to a total of 600 RPS. This is rarely what you want for simulating a global rate.
The "Constant Timer" (often used alongside the Constant Throughput Timer) adds a fixed delay after each sampler. This is useful for simulating realistic user think times. Without it, even with the Constant Throughput Timer, if your samplers are very fast, you might still hit the system too rapidly between the timer’s calculated delays. Adding a small, fixed delay (e.g., 500ms to 2000ms) makes the load more realistic.
What most people don’t realize is how the "Calculate Throughput based on: All active threads in all sessions" interacts with varying sampler response times. If your samplers become significantly slower than the target pacing, the timer will stop injecting delays. This can lead to a situation where, under heavy load, your actual throughput drops below the target because the system itself is the bottleneck, not the timer. The timer tries to enforce the rate but can’t magically make requests faster than they are.
The next common challenge you’ll face is ensuring your test plan accurately reflects the user experience under load, which often involves more sophisticated pacing and think-time distributions than the Constant Throughput Timer alone can provide.