I have Jmeter script with two thread group with two different API calls. My requirement is Thread Group 1 is to achieve 10 throughput per min and Thread Group 2 is to achieve 50 throughput per min. So I used constant throughput timer in the script.
When I run the test with above setting, thread group 2 is not achieving the expected throughput(50 per min) instead its only achieving the whatever the throughput defined in thread group 1's constant throughput timer(10 per min). I have kept 'this thread only" setting in the Timer.
Am I missing anything or some other setting needs to be done to achieve my requirement?
Your two groups are having different threads but you have also used Interthread communication Pre and Post processor's which works on FIFO concept as shown below.
For more info check this
Until its FIFO you cant achieve it. Instead, use properties to set the variables and get them in other thread. Check this.
Hope it help.
Related
In my application I want hit 20000 request in 10 hrs but I want distribute load in different time with different number of request means ex in 1 hrs 2000 request second hrs 3000 request third 1000 request like that how achieve this means how to separate load in diff time with diff no. of request
The easiest option is going for Throughput Shaping Timer, configuration implementing your described setup:
It's a good idea to use Concurrency Thread Group in combination with the Throughput Shaping Timer, they can be connected via Feedback Function so JMeter would be able to start extra threads if the current amount is not sufficient in order to reach/maintain the desired number of requests per second.
Both are JMeter Plugins and can be installed using JMeter Plugins Manager
Another solution could be using Constant Throughput Timer.
N.B. 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:
You could set the throughput using a property or variable.
Calculate the throughput values you need at different time intervals and set the property when the time is reached.
props.put("currentTPM", 120)
You will have some work in checking the duration since the test is started.
You may create a separate thread group to control the throughput. Rename the thread group name to TG-TM. Set the number of threads to 1 and loop count to infinite. Set the duration of the thread group.
def lstThrouputInOneHour= [2000,3000,1000,5000,4000,5000]
def currentIndex=vars.get("__jm__TG-TM__idx").toInteger()
if (currentIndex <lstThrouputInOneHour.size() ) {
def currentTPH=lstThrouputInOneHour[currentIndex]
def currentTPM=currentTPH.intdiv(60)
props.put("currentTPM",currentTPM.toString())
Thread.sleep(60*60*1000)
}
Note: Please introduce a startup delay to other thread groups to ensure they have access to the throughput value when they start.
This solution can be extended to work with Bean Shell Server where you could change the throughput values (JMeter properties) remotely
I am trying to configure a test for signup-login with invalid credentials imitating bruttforce attack. However, I want to make requests as a single user.
So the scenario is the next:
Request to sign up with valid params;
Attempt to log in with invalid params in a loop.
I am adding throughput timer but then I need to set up a high number of threads to generate for example 1 request per second.
How can I set exactly one user and run only one request per second in a loop?
UPDATE - SOLUTION
Everything was rather simple but still strange for me.
Maybe someone will face the same problem.
To get a number of requests per one user throughput timer should be placed not inside the controller but inside the thread itself.
To achieve Target Request Per Second use Throughout Shaping Timer : How to use Throughput Shaping Timer
JMeter Plugin link : Download from here
Few Important Notes:
JMeter threads of Thread Groups in scope of the Element will be
stopped when RPS schedule finishes.
Provide enough working threads for your RPS, JMeter timers can only delay threads (and limit RPS). You may pair this plugin with Concurrency Thread Group using Schedule Feedback Function to dynamically maintain thread count required to achieve target RPS.
If you're using versions of JMeter lower than 3.3 and if you have RPS that lower at the end of test, make threads to lower also. Оtherwise you'll have a spike in last second.
Avoid using zero RPS value as start of test, this produce spike also
Avoid zero RPS during the test, this may lead to nasty effects
Now, practical example showing 1 RPS for 1 User:
You might want to reconsider the location of the timer, it obeys JMeter Scoping Rules so it gets applied to all Samplers which are in your Thread Group.
If you want to apply it to only one - make it a child of the relevant sampler.
Also be aware that Constant Throughput Timer is precise enough on minute level so you might want to switch to the Precise Throughput Timer
I would like to execute a loop of HTTP requests with an incrementally number of users.
For example, I want something like that :
1st loop : 1 user
2nd loop : 2 users
3rd loop : 3 users
...
Is that possible with the JMeter GUI ?
Thanks in advance !
You can achieve this effect by using the Stepping thread group plugin
You can gradually increase the number of concurrent users in JMeter. But not in the way you are actually asking ie, every loop / iteration!
Simply - You can not change the thread count within the test once the JMeter test has started running . But you can use variables for the user count and supply to the test before the test starts.
To gradually increase the user count, you can use any of the below thread groups
You can use the regular thread group, ramp-up period. 100 users and 1000 seconds ramp up period, will add 1 user every 10 seconds.
Stepping Thread Group
Ultimate Thread Group
Actually JMeter doesn't allow this, however you can work it around using different approach, for instance if you stick to Requests Per Minute rather than to Virtual Users.
You can use Constant Throughput Timer to set desired initial throughput (i.e. N requests per minute) and increment it by desired factor each Thread Group iteration.
Despite word "Constant" in its name the throughput doesn't have to be constant, it can be a JMeter Variable or Function or JMeter Property.
Reference material:
How to use JMeter's Throughput Constant Timer
Beanshell Server
Throughput Shaping Timer - an advanced version available via JMeter Plugins, has some extra scheduling capabilities.
I have entered 500 to be the number of thread group and ramp up time to be 120 seconds but when the report is generated,the virtual users count is only 15 or in composite graph-active threads over time is raised to near about 12. So I am bit confuse active threads counts. Because the data(threads) or numbers that I filled in test plan before test is different and after result is different. What about scaled values in graph?and x10?Something related to threads?
Each JMeter thread representing a virtual user after initialization starts executing samplers upside down (or according to the Logic Controllers).
If thread doesn't have more samplers to execute and no more loops to iterate it's being shut down. It looks just like your case. See Max Users is Lower than Expected article for more detailed explanation and workaround.
Usually people set Loop Count to "Forever" and use Runtime Controller to so test could finish in designed time. Another option is using i.e. Ultimate Thread Group available via JMeter Plugins which provides convenient way of defining a load scenario.
My Test Plan have 3 Scenarios,
Submit Quote
Check Status
If Status Complete get Quote Details.
If I keep all these 3 scenarios in one thread then CTT is not putting constant throughput, when I remove create 2 thread 1 for Submit and other for Status and Get Details I am able to maintain CTT, but my 2nd and 3rd Scenario volume drops almost 50%. As I have dependency on 1st step I am using Thread communication and not sure how I can either get CTT in one thread or get same volume from 2 different threads.
Constant Throughput Timer is useful to shape the load where there is > 1 test iteration. If your thread group has only one iteration consider using Throughput Shaping Timer instead or play with ramp-up and thread number values. It is recommended to have only one instance of the CTT in your Test Plan as it's rather resource consuming by nature.
If your scenario assumes different throughput for different thread groups you can add a CTT per Thread Group (make sure that you select All active threads in current thread group (shared) in "Calculate Throughput based on" dropdown
If ITC test elements are throttling your test below desired throughput value consider using
__setProperty()
__property()
__threadNum()
functions to implement inter-thread communication instead. JMeter Properties are global, can be accessed from different thread groups and persist all the time while JMeter is running.
See How to use JMeter's Throughput Constant Timer for details.
If above information is not enough try to elaborate your query and include i.e. thread numbers, target throughput and what kind of information needs to be shared across thread groups.