Introduction to JMeter Google PlugIn - Timer

In this article we are going to see what are additional features/items added after installing jmeter plugin (Google Plugin) and what we can do with it. I will discuses about Timer only. To know about basic of jmeter see my this page. And, the process to install plug in , see this post.

What does a Timer do? A timer mainly wait for an event and it performs a task according to timer type. The google plug in provide us only one type of timer jp@gc - Throughput Shaping Timer. let's talk about that.

To add jp@gc - Throughput Shaping Timer.
-Right click a Test Plan or thread > Timer > jp@gc - Throughput Shaping Timer.

When we add a row,
Start RPS shows the scheduled Request Per Second start with.
End RPS shows the scheduled Request Per Second end with.
Duration meaning holding/running time in second.
The graph will show our setting's  visual representation.

I have made a scenario in the picture where the timer will define the execution according my settings.
I have made,
1. Start RPS with 1 and end up with 10 and running up to 5s
2. Another one Start RPS with 10 and end up with 10 and running up to 6s(no peak of RPS in graph)
3. Another one Start RPS with 15 and end up with 15 and running up to 7s
4. Another one Start RPS with 30 and end up with 30 and running up to 4s
5. Another one Start RPS with 20 and end up with 15 and running up to 2s(RPS is getting down)
6. Another one Start RPS with 15 and end up with 1 and running up to 5s(RPS at the bottom)



What will happen in while in the running the test? This timer will wait for the execution and perform according to the settings to have accurate scenario generated.

-We can also put "load_profile=" in the jmeter.properties to define those values.Ex-load_profile=const(10,5s) line(10,30,17s) step(10,35,5,30s)
Meaning : Hold constant load 10RPS up to 5s, Increase from 10RPS to 30RPS in 17s, generate stepping load from 10RPS to 35RPS during 30s, where increment 5RPS.

-While making test plan, Generally Thread = RPS*Response Time(ms)/1000. So, more RPS means more threads. (Ex-If we have response time 3.5s(=3500ms), and we need RPS=2000, so thread=2000*3500/1000=7000)

-When RPS schedule finis Test will be stopped
-Make a test plan having enough threads, as timers can only delay threads (and limit RPS). That means, this will organize the thread. So, if you are planing for higher RPS then thread , it will not work
-Better to generate goolge thread plugin with this.If your RPS lower at the end of test, you should make thread lower also. Because, without that it may cause error in the end.
-Don't put zero RPS value as start or end or middle of the test

And we can easily monitor the effect using jp@gc - Transactions per Second listener.

Thanks...:)