I need to divide the load on my application with some percentages i.e. Login Module - 60%, Accounts - 10%, Other Modules - 30%. After few research i find a option under Throughput Controller section in jmeter using which i can control these percentages. I find one checkbox there named "per user". Now i am not getting this check box.
As per blazemeter blog here i tried one scenario as below with "Per user" checkbox checked.
Select "Total Execution" from dropdown.
Marked Throughput as 40.
Threads used - 10, Loop count 1
Now, as per the blog specific transactions should execute for 400 times. but there was Zero execution for that transaction.
I tried another scenario with "Per user" checkbox checked.
Select "Total Execution" from dropdown.
Marked Throughput as 60.
Threads used - 10, Loop count 1
Now, as per the blog specific transactions should execute for 600 times. but it executed 10 times.
Can any experts out there share what am i doing wrong here? Or there is some more clarity needed how this checkbox works.
To understand the Throughput Controller (TC), just add one TC and one sampler (inside TC) and Aggregate Report in combination. then, play with all the parameters in the Throughput Controller.
From Official Documentation:
Total executions:
causes the controller to stop executing after a certain number of executions have occurred.
and
Per User: If checked, per user will cause the controller to calculate
whether it should execute on a per user (per thread) basis. If
unchecked, then the calculation will be global for all users. For
example, if using total execution mode, and uncheck "per user", then
the number given for throughput will be the total number of executions
made. If "per user" is checked, then the total number of executions
would be the number of users times the number given for throughput.
Read both the statements carefully multiple times.
In both the scenarios that you specified, you have maximum executions of 10. (Thread count * Loop Count). Though you specified, Total Executions as 40 or 60, First, you should provide more than 60, in order to see all those 40/60 iterations get executed. So, always specify more iterations (using Thread count & Loop Count) than the Total Executions.
You have to consider Percentage Executions instead of Total Executions to match your requirements. Again, I suggest to simulate for one sample and understand the behaviour by varying the percentages.
Following are some scenarios and expected behaviour (EB).
Scenario:1
Thread Group - 10, Loop Count - 1, Throughput - 40 (Total Executions), Per User - Checked.
EB: Sampler will run only 10 times.
Scenario:2
Thread Group - 40, Loop Count - 1, Throughput - 40 (Total Executions), Per User - Checked.
EB: Sampler will run only 40 times.
Scenario:3
Thread Group - 40, Loop Count - 1, Throughput - 40 (Total Executions), Per User - Unchecked.
EB: Sampler will run only 40 times.
Scenario:4
Thread Group - 100, Loop Count - 1, Throughput - 40 (Total Executions), Per User - Checked.
EB: Sampler will run only 100 times. calculated whether each user executed 40 times. As the limit is not reached, it is executes all 100 iterations.
Scenario:5
Thread Group - 100, Loop Count - 1, Throughput - 40 (Total Executions), Per User - Unchecked.
EB: Sampler will run only 40 times. calculated at the global level. As the sampler reached 40 times for all the threads, stops executing it.
Scenario:6
Thread Group - 100, Loop Count - 40, Throughput - 40 (Total Executions), Per User - Checked.
EB: Sampler will run 400 times (Each user -> 40 times, 100*40). calculated whether each user executed 40 times. Here, even each user limit is also reached and no more executions after 40.
Scenario:7
Thread Group - 100, Loop Count - 1, Throughput - 40 (Total Executions), Per User - Unchecked.
EB: Sampler will run only 40 times. calculated at the global level. As the sampler reached 40 times for all the threads, stops executing it.
Related
Can someone explain to me if the loop sets the number of requests or it`s there to have an average?
If I have 100 users, ramp - up set as 0 and loop 1, does it mean that I have only 100 users and if I increase the loop to 2, does it mean that there will be 200 users doing the request?
If I needed to test with 200 users, why would I not set the users to 200? What does the loop do differently and how does it affect the result?
If you have only one request (sampler) under the Thread Group:
With loop count 1 - 100 users will execute 1 request 1 time each, 100 requests in total
With loop count 2 - 100 users will execute 1 request 2 times each, 200 requests in total
With regards to setting ramp-up to 0 - it's not the best idea, it is good to increase the load gradually, this way you will be able to correlate increasing load with other performance metrics, in particular with response time and number of requests per second.
More information: JMeter Ramp-Up - The Ultimate Guide
P.S. It might be easier to consider i.e. Ultimate Thread Group which makes the process of defining the workload easier, for example here is how you can configure JMeter to start with 1 user, increase the load up to 200 users in 60 seconds, hold the load for another 60 seconds and then gradually decrease the load:
You can install Ultimate Thread Group as a part of Custom Thread Groups bundle using JMeter Plugins Manager
I have a problem with JMeter that I can't figure out.
I have 3 requests in one thread group. Each request needs to be executed 5000 times in 5 minutes which means I need to execute 15 000 requests in 5 minutes altogether.
The thread group is set up like this:
Number of threads (users): 50
Ramp-up period: 1
Loop count: forever
Duration (seconds): 300
Each request has a Constant throughput Timer:
Target throughput: 1000.0
Calculate Throughput based on: all active threads in current thread group
And the results after the test run is complete are around 2000-3000 requests and that is too low. I can't figure out which settings are wrong.
Tests are ran in non-GUI mode on an Azure virtual machine with a Intel Xeon E5-2673 #2.3 GHz with 16 cores and 32gb of RAM and the server is more than capable of executing more requests since the response time is about 1 second so hardware should not pose a problem. JMeter heap memory is set to 12 GB.
Any help is appreciated!
I have 3 requests in one thread group. Each request needs to be executed 5000 times in 5 minutes which means I need to execute 15 000 requests in 5 minutes altogether.
That means you have to execute thread group for 5000 times in 5 mins => 300 seconds. If you execute thread group that much of time, you will automatically generate 15k requests.
From Documentation:-
Loop Count Number of times to perform the test case. Alternatively, "forever" can be selected causing the test to run until manually stopped.
When you set loop count: forever or any value in loop count for that matter, it means you want next set of users(threads) [which you have defined as 50 now], only when you are done with the first set 50 users request (150 requests as each thread group as 3 requests). Now, this 50 users request may take unexpected time and your next set will be returned only after this 50 users are done.
So to solve the problem at hand, you should have the following configuration for the thread group :
Number of threads (users): 5000
Ramp-up period: 300
Loop count: 1
So this means after every second around 17 Threads would be on-boarded.
To achieve your desired value configure the following
Number of threads (users): 50 / 60
Ramp-up period: 30
Loop count: forever
Duration (seconds): 300
It is good practice to give some ramp up time.
Also Constant Throughput Timer works on minute level and your desired throughput should be
Target throughput (in minutes): 3000.0
Calculate Throughput based on: all active threads in current thread group
So now, in 1 minute, JMeter will try to send 3000 requests and in 5 minutes, request count will be more or less around 15000.
Here are a few recommendations to tackle tests like this:
Use Ultimate Thread Group to create the threads required to run your tests.
Increase the total number of threads to 150-200 - Depending on the response time of your requests, 50 threads may be busy and you are not able to scale beyond certain throughput.
Add throughput shaping timer under Ultimate thread group, to maintain the throughput of 50RPS for 5 minutes(300 Seconds).
The combination of Ultimate Thread Group and Throughput Shaping Timer will allow you to have granular control over your requests and RPS you want to achieve.
Set Ulitmate Thread Group and Throughput Shaping Timer as below.
Put all your requests below Throughput Shaping Timer and you should be able to achieve the expected load.
Try to use Stepping thread group. It will allow you to send 50 user per second upto 300 second.
Download jar from below link.
https://jmeter-plugins.org/wiki/SteppingThreadGroup/
I have about 300 users (configured in the thread group) who would perform an activity (e.g.: run an e-learning course) twice. That would mean I need to expect about 600 iterations i.e 300 users performing an activity twice.
My thread group contains the following transaction controllers:
Login
Dashboard
Launch Course
Complete Course
Logout
As I need 600 iterations per 5400 seconds i.e 3600 + 900 + 900 seconds (1 hour steady state + 15 mins ramp-up and 15 mins ramp-down), and the sum of sampler requests within the total thread group are 18, would I be correct to say I need about 2 RPS?
Total number of iterations * number of requests per iteration = Total number of requests
600 * 18 = 10800
Total number of requests / Total test duration in seconds = Requests per second
10800 / 5400 = 2
Are my calculations correct?
In addition, what is the best approach to achieve the expected throughput?
Your calculation looks more or less correct. If you need to limit your test throughput to 2 RPS you can do it using Constant Throughput Timer or Throughput Shaping Timer.
However 2 RPS is nothing more than statistical noise, my expectation is that you need much higher load to really test your application performance, i.e.
Simulate the anticipated number of users for a short period. Don't care about iterations, just let your test to run i.e. for an hour with the number of users you expect. This is called load testing
Do the same but for longer period of time (i.e. overnight or weekend). This is called soak testing.
Gradually increase the number of users until you will see errors or response time will start exceeding acceptable thresholds. This is called stress testing.
There are many questions/answers available here to understand Ramp up time but I want to get something in detail for my test case.
Test Case : Expecting 1200 users per 5 minutes on the home page. So it will be like 5 users/second.
I have set following thread properties :
No. of Threads : 1200
Ramp-up Time - ? [I am not sure what to set]
Loop count - Forever
Scheduler - 300 Seconds[5 Minutes]
Can anyone please help me to set ramp up time for my test case? I am running the test on my local machine.
I want to check that how many users server can handle in 5 minutes. Our expectation is 1200 users.
As per you test case and duration settings, I think, you are making confusion with the Threads and Requests.
In short: You must use Ramp-up as 240 seconds for this scenario.
Let me describe you in details:
Ramp up is the time in which all the users arrive on your tested application server.
Requests are simulated by samplers but threads are the simulation of users.
Please note- The total number of requests are related to throughput, Whereas the number of active threads performing the same activity is related to concurrency.
From your requirements, I assume you want to measure the throughput which is related to the requests/second not the users per second. To achieve this, you can use a Constant Throughput Timer at your test plan level.
Constant Throughput timer allows you maintain throughput of your server (requests/sec). Here requests are samplers. Threads are users/clients which are requesting server using samplers.
You can achieve this by using both "Thread Group" or "Ultimate Thread Group".
As far as I know, it doesn't matter which type of Thread group you are using with Constant Throughput timer, at the end of the test in the results, you will get your desired Throughput which you mentioned in Constant Throughput Timer i.e. if you have mentioned 1200/min in Constant Throughput Timer with "Calculate Throughput based on" value as "All active threads" and there are 3 requests (samplers) in your thread group then JMeter will manage the requests in a way that it will generate only 6.6 requests/sec for each sampler i.e. 1200/min is divided among 3 requests, it doesn't matter whether you are using Ultimate Thread Group or the Thread Group; Throughput timer works in same way for all types of thread groups.
Now as per your requirement: (Using Thread Group):
No. of Threads : 1200
Ramp-up Time - 240 (Since you want 5 users per second, 1200/5= 240)
Loop count - Forever
Scheduler (Duration) - 780 Seconds [13 Minutes]
IMPORTANT:
Thread Group configurations will be the same which you have already mentioned. Number of threads will be the client load which you want to put(in you case it's 1200), duration : (240+300+240), loop : forever, ramp-up : 240 yes when you ramp up i.e. in the first minute generally you get more requests as threads are starting so it is normal behavior. To test your scenario run for exactly 5 minutes, you should test for 13 minutes. Exclude first 4 min and last 4 min of the test as that is warm up time for your test as well as server and last 4 min are warm down period.
Now as per your requirement: (Using Ultimate Thread Group):
Start Thread Count: 1200
Initial delay, sec: 0
Startup, sec: 240 (I assume you want 5 users come to your application for requesting expected samples per second)
Hold Load for: 300 sec (Since you required 5 minutes to test for 1200 users)
Shutdown Time, sec: 240
You can set just like this:
Don't get confuse the Thread number with the number of requests, each thread will create multiple requests for seconds in field Hold Load for.
Rampup is the speed at which users arrive on your application.
The number you put means that once it is reached all threads have been started.
The tiniest it is , the faster users arrive.
So nobody can answer that for you, you need to analyse your traffic.
Regarding the number of threads, 1200 threads might not be the good number, as 1200 users can navigate on application slowly or rapidly.
What you need is add a Constant Throughput Timer to control how much transactions per second you'll be reaching.
You should use the Ultimate Thread Group plugins available in Standard set.
To maintain concurrency the configuration should be like this:
Start Thread Count: 1200
Initial delay, sec: 0
Startup, sec: 60
Hold Load: 180
Shutdown Time, sec: 60
Ultimate Thread Group
Here all the 1200 threads will be generated and up within 60 sec of Startup time(Ramp up time) .Those 1200 threads will be active for next 180 sec, and after that, those threads will shut down within next 60 sec.
So overall duration of the test is 300 sec as you desire. Throughout the Hold Load time(180sec) the requests will be looped.
This ultimate thread group will give you more control over Threads.
Now if you want to control the rate of transactions per second or the number of samples to execute you can use Constant Throughput Timer. Constant Throughput Timer will let you control the flow of requests to be sent. The default "Thread Group" only control the way the users or threads will be generated.It doesn't control the rate of requests to be hit your application.So for this purpose, you could use "Constant Throughput Timer" to control your requests per second. For further detail, you could go through JMeter documentation.
I received a JMeter script from someone, a script that contains 3 Throughput Controllers. The strange part is that they have "Percent Executions" selected and summing the Throughput from each of the controllers I only reach 70 ( the First one has a throughput of 40, second one 20 and third one 10). The questions are:
1. Shouldn't their sum be 100 (100%) ?
2. If the sum is 70 and the first one has a throughput of 40, does it mean that the first throughput controller will run 40% of the sum of 70?
3. Could someone give me more details related to "Percent executions vs Total executions"?
-JMeter help doesn't help much.
The Throughput Controller can operate in 2 modes:
Total Executions :- defines how many times the child elements will be executed (absolute number).
(A). If “Per User” is unchecked - the underlying sampler(s) will be executed as many times as defined in the Throughput field. For instance, if you have 100 users, the throughput of 100 and the box is unchecked, the underlying test elements will be executed 100 times.
(B). If “Per User” is checked - the child sampler(s) will be executed as many times as defined in the Throughput field, multiplied by the “Number of Threads” in the current Thread Group. For instance, if you have 100 users, the throughput of 100 and the box is checked, underlying test elements will be executed 100,000 times.
Percent Executions:- the child elements will be executed according to the percentage of iterations (threads * loops) as defined in the Throughput” field.
All these information is quoted from BlazeMeter Blog about Using Throughput Controller with Different Execution Percentages. This blog will help you understand your test executions scenario as per your configuration of Throughput Controller inside the Test Script.