In this article, we will discuss about the next set of elements i.e Timers, importance of timers, types of timers and their usage in our test. In case if you have missed the older articles, click here 1, 2, 3, 4.
Apache JMeter sends requests to the target server without pausing between each request by default. In that case, the target server can be over flooded with numerous requests with in a very short span which may lead to server overload. So how to prevent jmeter from overloading the target server and how to pace each request in our test execution to achieve real time behavior. The answers is quite simple Timer. 🙂
Timers allow JMeter to delay between each request which a thread makes. Timer can solve the server overload problem. Also, in real life visitors do not arrive at a website all at the same time, but at different time intervals. So Timer will help mimic the real time behavior.
Timers are only processed in conjunction with a sampler. A timer which is not in the same scope as a sampler will not be processed at all. To apply a timer to a single sampler, add the timer as a child element of the sampler. If a timer is placed before a sampler in the test script, timer will be applied before executing before any sampler. To apply a timer after a sampler, either add it to the next sampler, or add it as the child of a Test Sampler.
Types of timers in JMeter
Apache JMeter provides various types of timers to pace your request to avoid overloading of the target server and also to provide think time between users actions to achieve real time behavior.
This timer is used when if you have to pause each thread for the same amount of time between requests. Lets examine in details with a simple example, we have a scenario where 5 threads will be fired to the target server and each thread has to be paused for 1000 milliseconds. Your constant timer setup should be like this:
After adding the constant timer and thread delay, test plan should be like this:
Now configure your thread group in such a way that 5 threads will be send to target server and run the test scenario. Test results can be as follows:
From the above picture, we can clearly understand that each thread is sent to server after pausing for 1000 milliseconds i.e start time to thread or sample 1 is 18:22:24 and start time of sample 2 is 18:22:25 as you can notice there is a 1000 millisecond or 1 sec delay between the threads and for rest of the samples also.
Uniform Random Timer
This timer pauses each thread request for a random amount of time, with each time interval having the same probability of occurring. In detail, lets say random delay attribute in the timer is configured to 1000 milliseconds as in the below picture and we are sending 5 requests to the server it means that maximum random delay between each request will not exceed more than 1000 milliseconds.
Lets examine in detail with an example, we have a scenario where 5 threads will be fired to the target server and requests has to be passed randomly. Configure your thread group in such a way that it sends only 5 requests to the server and run the test. The test results can be as follows:
From the above test results, we can understand that sampler or request 1 was fired at 11:58:45:833 and the second sampler was fired at 11:58:46:457. If you observer the delay between request 1 and 2 is 624 milliseconds which is clearly less than the maximum delay(1000 milliseconds) configured. That’s it, pausing request samplers for random amount of time can be easily achieved with this timer.
If constant delay offset is set to a value then the total delay between each request sampler will be the sum of the random value and the offset value.
Random delay + constant offset delay = Total delay
The purpose of the SyncTimer is to block threads until X number of threads have been blocked, and then they are all released at once. A SyncTimer can thus create large instant loads at various points of the test plan.
The number of simulated users to group by attribute indicates that the number of threads to release at once. Setting it to ‘0’is equivalent to setting it to number of threads in Thread Group. If the attribute is set to 2 which means that each 2 threads are released at once as a group.
Here is a simple example that explains how to use synchronizing timer. We all are aware of that eCommerce online shopping web sites are creating a huge buzz these days and thousands of products are sold online. In that case, there is a possibility that larger number of users will be trying to buy a same product almost at same point time. For example Xaiomi mobiles are sold through Flipkart where millions of users will be trying to buy this product at the same point of time, so millions of requests will be sent and server should be capable of withstanding this huge traffic. We can use synTimer to simulate this real behavior as this timer manages to send the requests at almost same point of time. We have simple case where 5 user requests will be sent to server at same point of time and we can simulate how server can behave under such situations. Following are the test results for such simple behavior:
From the above picture, we can witness that all the requests are send to the server at almost same point of time.
Gaussian Random Timer
This timer pauses each thread request for a random amount of time, with most of the time intervals occurring near a particular value. The total delay is the sum of the Gaussian distributed value (with mean 0.0 and standard deviation 1.0) times the deviation value you specify, and the offset value. Another way to explain it, in Gaussian Random Timer, the variation around constant offset has a Gaussian curve distribution.
For example: If deviation and offset delay are set to 100 and 300, the delay between each request sampler can vary between 200 ms (300 – 100) and 400 ms (300 + 100) based on Gauss distribution.
Constant Throughput Timer
This timer introduces variable pauses, calculated to keep the total throughput (in terms of samples per minute) as close as possible to a give figure. Of course the throughput will be lower if the server is not capable of handling it, or if other timers or time-consuming test elements prevent it.
Although the Timer is called the Constant Throughput timer, the throughput value does not need to be constant. It can be defined in terms of a variable or function call, and the value can be changed during a test. The value can be changed in various ways:
- using a counter variable.
- using the remote BeanShell server to change a JMeter property.
Calculate Throughput based on:
This thread only – each thread will try to maintain the target throughput. The overall throughput will be proportional to the number of active threads.
All active threads in current thread group – the target throughput is divided amongst all the active threads in the group. Each thread will delay as needed, based on when it last ran.
All active threads – the target throughput is divided amongst all the active threads in all Thread Groups. Each thread will delay as needed, based on when it last ran. In this case, each other Thread Group will need a Constant Throughput timer with the same settings.
All active threads in current thread group (shared) – as above, but each thread is delayed based on when any thread in the group last ran.
All active threads (shared) – as above; each thread is delayed based on when any thread last ran.
If you enjoy reading article then you can subscribe our updates for FREE, just add your email id . I will keep on updating the article for latest testing information. Subscribe and stay tuned for updates, there’s lot more to come.
🙂 Happy Performance Testing !! 🙂