Introduction to JMeter Constant Throughput Timer
A constant throughput timer in JMeter is used to achieve the actual output by computing the total number of requests. The timer tries to produce a constant throughput till the end of the test to achieve the target. So if the server could not manage the load, it results in minimum throughput. It may decrease if other timers deny the constant throughput timer. So it is not advised to use other timers with constant throughput timers. In this article, using, configuration, and examples of constant throughput timers are discussed in brief.
What is the JMeter constant throughput timer?
If the user wants to execute a target-type case, where the goal is not to stimulate many concurrent users, but the request number per second falls within the defined time, then constant throughput time is used. It works precisely like a minute level and ensures that the test duration doesn’t last long, like more than a minute, and the user implies a reasonable ramp-up time to avoid spikes.
Other timers can impact the target of the constant throughput timer, and it is not advised to use it with other timers. To achieve the correct sampler count at the test end, the user should neglect the transaction count from the cumulative report to ensure the constant throughput timer is functioning correctly or not. The target achieved is high. The threads are not aborted smoothly. At the end of the test duration, all threads are stopped, and sometimes, they are in the middle of an iteration. The user must fix the number of threads to prepare the real-time scenario. The Spike test scenario and the step-up case are not prepared with a constant throughput timer.
How to use the JMeter constant throughput timer?
Choose the suitable elements where the user wants to include the timer. It can be a test plan, thread group, controller, or sampler. Right-click on the configuration element and choose to add. Choose the timer from the pane and select the constant throughput timer.
The mandatory input fields like name, target throughput, calculate throughput, comments, active thread, and shared active thread must be configured in a constant throughput timer.
- Provide the appropriate name of the timer in the name field.
- Provide related and descriptive notes in the comments section.
- Target throughput is computed in samples per minute. The number of requests which need to be produced in a minute should be mentioned. For example, if the user wants to achieve 5000 requests in an hour, then the target throughput value should be around 5000/60 = 83. Here the target throughput value is 83.
Compute the throughput based on the requirement. The option, ‘this thread only,’ enables every thread to manage its target throughput regardless of any group. The entire throughput is proportional to the count of active threads. For example, if ten users have ten samplers and the target throughput value is set to five seconds, then every thread will send five requests per minute individually. So the request triggered after one minute is 10 * 5 = 50, and every thread will send five requests per minute.
All active threads in a current thread group are delegated among all the active threads present in the group. So every thread can be configured based on the last execution. So all thread works in a systematic method. There is another option; all active threads segregate the target throughput between all the threads in the thread group. So every thread will get delayed as per the requirement and works based on all the last execution. In this case, all thread group requires a constant throughput timer with similar settings.
The shared thread group has all active threads in the current thread group. So if the user chooses this option, the target throughput is segregated among all the active threads in the concerned group. Still, every thread is executed delayed based on the last execution of the group. For example, consider if five users have five samplers, and 7 seconds is set as the target throughput value. Now a total of seven requests will be sent together in a minute. So after a minute, the triggered request will be seven.
Shared active threads are an option that segregates the target throughput among all the active threads present in all the thread groups. Every thread is executed in delay based on the last execution. For example, consider that there are two thread groups with five users, 1st thread group has two users, and the second thread group has three users with five samplers. Here eight are set as target throughput values, and now eight requests are sent per minute. So, after a minute, the triggered request will be eight.
Constant throughput timer Examples
As discussed above, the timers in JMeter are important for maintaining the performance test. However, other timers are readily available as a plugin to implement in the test plan and check the plan’s performance. The popular timers in JMeter are a constant timer, uniform random timer, Gaussian random timer, precise throughput timer, synchronizing timer, Beanshell timer, and JSR223 timer.
The Gaussian random time is easy to use and helps to view statistical analysis, also called a bell curve. The random poison timer is the same as the Gaussian random timer, but it works fast without delay. Lambda is used to calculate the random values to prevent the delay in performance tests. JSR223 times are flexible and allow the user to script and fix the delays. So it may be complex or simple according to the test.
Conclusion
Though the timer is a constant throughput timer, the value doesn’t require to be constant, and it can be changed at the test. It can be set to preferred settings via counter variable, Beanshell function, JavaScript, and the remote BeanShell to change the property of JMeter.
Recommended Articles
This is a guide to JMeter Constant Throughput Timer. Here we discuss the using, configuration, and examples of constant throughput timers are discussed in brief. You may also look at the following articles to learn more –
