JMeter Constant Throughput Timer : Tutorial

Setting 100 threads in JMeter does not guarantee a fixed request rate. If the server responds quickly, those threads may send more requests than expected. If response times increase, they stay busy longer and the request rate drops.

This matters when your test requirement is based on traffic rather than concurrent users. You may need to test an API at 3,000 requests per minute or reproduce a transaction rate seen in production. Thread count gives JMeter enough users to generate load, but it does not control how quickly they send requests.

The Constant Throughput Timer controls that pace by pausing threads before sampler execution. It can slow requests to match a target rate, but it cannot generate throughput that your thread count, response times, or load generator cannot support. Its placement and calculation mode also decide whether that rate applies per thread, per thread group, or across the test plan.

Before configuring it, you need to understand where it fits among JMeter’s other timers and how throughput is measured during a test.

What Is JMeter Throughput?

Throughput tells you how many requests JMeter completes within a given period. You will usually read it as requests per second or requests per minute in reports such as the Aggregate Report and Summary Report.

It is important not to treat throughput as the same thing as thread count. Threads represent concurrent virtual users, while throughput represents the rate of completed samples. Ten threads can produce very different throughput values depending on response time, timer delays, test logic, and how long each thread remains occupied.

For example, if each request completes quickly, the same threads can run more samples within a minute. If response times increase, those threads wait longer before starting the next iteration, so throughput falls even though the thread count has not changed.

Why JMeter Throughput Is Needed For Testing

Throughput gives you a way to check whether the test generated the workload you intended and whether the system handled it without crossing acceptable response time or error limits. It becomes especially useful when the requirement is written as transactions per second, API calls per minute, or orders processed per hour.

You can use it to answer a few practical questions:

• Did the test reach the required load? A test configured for 1,000 requests per minute is not valid if JMeter only achieved 700. Checking the actual throughput prevents you from drawing conclusions from an underloaded test.
• Where does the system begin to lose capacity? As load increases, throughput should rise with it. If throughput stops increasing while response time and thread utilisation continue to grow, the system may have reached a bottleneck.

• Did a new build affect processing capacity? Running the same workload against two builds lets you compare how many requests each one completes within the same time and performance limits.
• Can the application meet its traffic target? Throughput helps validate whether the system can sustain the expected production rate while keeping failures and response times within the agreed thresholds.

Throughput is therefore both a workload check and a result metric. JMeter may be configured to send a target rate, but you still need to verify the rate it actually achieved. The Constant Throughput Timer helps control that request pace during execution.

Different Types of JMeter Timers

Timers in JMeter control when a sampler runs, which directly affects the traffic pattern your test produces. The right timer depends on whether you want to model user think time, spread requests over time, maintain a target rate, or release several threads together.

Here is where each timer fits:

• Constant Timer: Adds the same delay before every sampler in its scope. Use it when each user action should have a fixed pause, such as waiting two seconds between opening a page and submitting a form.
• Uniform Random Timer: Adds a random delay within a defined range. It is useful when you want variation between users without allowing a few unusually long pauses to distort the test.
• Gaussian Random Timer: Produces delays around an average value, with most pauses staying close to that average. Use it when user wait times tend to cluster around a common value rather than being spread evenly.
• Poisson Random Timer: Generates delays based on a Poisson distribution. It is more suitable for modelling independent events, such as requests arriving at uneven intervals from separate users or systems.
• Constant Throughput Timer: Delays sampler execution to keep the average request rate near a configured target. Use it when your workload is defined in requests per second or requests per minute instead of concurrent users.
• Synchronizing Timer: Blocks threads until a specified number are ready, then releases them together. This is useful for testing short bursts, such as many users submitting a request at the same time.
• JSR223 Timer: Lets you calculate delays with Groovy when built-in timers cannot represent the required behaviour. It can use variables, test data, or runtime conditions to decide how long each thread should wait.

What is Constant Throughput Timer?

The Constant Throughput Timer controls how often JMeter starts samples. You set a target in samples per minute, and JMeter inserts delays before sampler execution to keep the average rate close to that value.

For example, a target of 600 samples per minute means JMeter will try to maintain an average of 10 samples per second. The exact spacing between requests depends on the selected calculation mode and the number of active threads sharing the target.

The timer only adds waiting time. It does not create threads, speed up requests, or force JMeter to reach a rate that the test environment cannot support. If response times are high or too few threads are available, the achieved throughput may remain below the configured value.

Constant Throughput Timer vs Throughput Controller

While both the Constant Throughput Timer and Throughput Controller help regulate test execution in JMeter, they serve different purposes and are used in different contexts.

Constant Throughput Timer ensures requests are sent at a consistent, defined rate over time, while the throughput controller controls how often specific parts of the test plan are executed based on percentage or count.

In summary, the Constant Throughput Timer is ideal for managing test intensity, while the Throughput Controller is best for simulating varied user behaviors within a scenario.

Input Fields of the ‘Constant Throughput Timer’

This timer provides simple yet powerful configuration options to control how throughput is applied during test execution. Understanding these input fields is key to using the timer effectively.

Target Throughput (in samples per minute): Defines the number of requests to be sent per minute. For example, 120 means the system will aim for 2 requests per second.

Calculate Throughput based on: Determines the scope of throughput distribution. Options include:

• This thread only: Applies the throughput target individually to each thread.
• All active threads in the current thread group: Distributes the throughput across all threads within the selected thread group.
• All active threads: Applies the throughput target across all threads in the entire test plan.
• All active threads in current thread group (shared): Shares the throughput limit across all threads in the thread group.
• All active threads (shared): Shares the throughput across all active threads in all thread groups.

These settings allow flexible control over request distribution, making it easier to simulate a realistic user load.

How to Use the JMeter Constant Throughput Timer

The Constant Throughput Timer is used to apply a fixed load pattern during performance testing. It can be combined with thread groups and samplers to simulate a consistent number of requests over time. Below is a step-by-step example to demonstrate its usage in a simple HTTP request test.

Scenario: Simulate a load of 60 requests per minute (1 request per second) on a placeholder sampler for a duration.

Test Plan Setup

1. Thread Group: Add a Thread Group to your Test Plan.

• Set “Number of Threads (users)” to a value potentially higher than needed to achieve the target (e.g., 10 users) to ensure enough threads are available to generate the load if the system is responsive.
• Set “Ramp-up period (seconds)” to a small value (e.g., 5 seconds).
• Specify a duration in the Thread Group or Set “Loop Count” to “Infinite.

2. Sampler: Add a sampler under the Thread Group. An “HTTP Request” pointed at a simple URL.

3. Constant Throughput Timer: Add a Constant Throughput Timer under the Thread Group.

• Target Throughput (in samples per minute): Set this to 60.0. This is the desired rate of 60 samples every minute (1 sample per second).
• Calculate Throughput based on: Select “all active threads in current thread group”. This tells the timer to consider the total requests from all threads in this Thread Group when calculating the delay needed to maintain the 60 samples/minute rate.

4. Listeners: Add an “Aggregate Report” and a “View Results Tree” listener to the Test Plan (preferably under the Test Plan element to see results for everything).

Execution

Upon running, the threads execute samplers. The Constant Throughput Timer intervenes before each eligible sampler, introducing pauses as necessary to ensure the collective rate of sampler executions across all active threads averages out to the specified target throughput (60 samples/minute).

Output

Examine the “Throughput” column in the Aggregate Report. A value of 1.0/sec (which is equivalent to 60 samples per minute) confirms that the Constant Throughput Timer successfully regulated the execution pace. By introducing necessary pauses between requests, the timer enabled the test to collectively maintain an average rate of approximately 1 sample per second across all active threads over the test’s duration, aligning with the target of 60 samples per minute set in the timer.

Best Practices for Working with a Constant Throughput Timer Element

A Constant Throughput Timer can be configured in a few clicks, but a valid test depends on how you derive the target, scope the timer, and provide enough threads to sustain the rate.

• Convert business traffic into samples before setting the target: Production data may show orders, searches, or user journeys per minute, while the timer works with samples per minute. If one journey sends four HTTP requests, 500 journeys per minute may require a target closer to 2,000 samples per minute.

• Use a shared calculation mode for a combined target: A per-thread mode applies the configured throughput to every thread. Setting 600 samples per minute with ten threads can therefore produce a much higher total rate than expected. Use a shared mode when the target represents traffic for the complete Thread Group or test plan.
• Place the timer only where the rate should apply: A timer affects every sampler within its scope. Placing it at the Thread Group level may throttle login, API, static resource, and logout requests together. Put it under a controller when you only need to regulate one transaction or request path.

• Provide enough threads to maintain the target: The timer can delay requests, but it cannot make occupied threads available sooner. As response time increases, you need more concurrent threads to maintain the same request rate. Run a small calibration test first and confirm that JMeter can reach the target without exhausting the available threads.
• Account for other delays in the same execution path: Think-time timers, pacing logic, retries, and script-level waits all reduce how often a thread can start the next sample. Review the complete request path instead of adjusting the Constant Throughput Timer in isolation.
• Check the achieved rate over a stable test window: Throughput may be lower during ramp-up and may fluctuate in short tests. Compare the target with the rate achieved during the steady-state period, then review response time and errors to confirm the system sustained that load.
• Keep heavy listeners out of the load test: Listeners such as View Results Tree consume memory and processing capacity when they retain large result sets. Use them while debugging with a small workload, then disable them for the main run and analyse the generated results afterwards.

Conclusion

The Constant Throughput Timer is useful when your workload is defined by request rate rather than user count. It lets you pace sampler execution toward a target, but it does not guarantee that JMeter will reach that target. Thread availability, response time, timer scope, and calculation mode still determine the actual throughput.

Start with a rate taken from production traffic or a clear test requirement. Convert business transactions into JMeter samples, choose the correct shared or per-thread mode, and confirm the achieved throughput during the steady-state period. If the rate falls short, check thread capacity and response times before increasing the target or changing the timer.