I had got stats from log which stated that on avg we have peak load of 3000 logons in 1 hour.
How do I work out the rampup period for jmeter to replicate the same behaviour in 1 hour or 30 mins or 2hr duration
It is not about the ramp-up period, it is more about limiting the rate of requests which are being sent by JMeter to certain rate. So you should be looking at Constant Throughput Timer in order to limit JMeter's throughput to the desired rate.
For example,
If you want 3000 logins per hour it stands for 50 logins per minute add Constant Throughput Timer as a child of the "Login" request and configure it as follows:
Target Throughput: 50.0
Calculate Throughput based on: all active threads
Similarly if you want 3000 logins in 30 minutes - Throughput should be 2x times higher: 100.0 samples per minute
And finally if you want 3000 logins in 2 hours - the Throughput should be 2x times lower: 25.0 samples per minute
You might also be interested in Throughput Shaping Timer, it acts similar to the Constant Throughput Timer but it is more precise when it comes to periods lesser than 1 minute and you can also create "Load Profiles" with it. You can install Throughput Shaping Timer using JMeter Plugins Manager.
Related
I am trying to send 1100 requests per minute to my API endpoint for a period of 5 minutes, so in total, I will make 5500 requests to the endpoint.
Based on the above requirement, Here is how I have set up my Jmeter:
It seems like I have misconfigured Jmeter, because in the end I can see Jmeter has made 8401 requests to the API instead of 5500.
What have I missed in the configuration?
Does the "Infinite" check-box need to be checked or unchecked?
The number of requests you're expecting (which is 5500) for this test plan is wrong.
As per your expectation, I think, you are making confusion between the Threads and Requests.
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.
According to your test plan:
- Total Number of Threads: 1100 vitual users
- Ramp-up time: 60 (1 min)
- Loop count: Infinite
- Test duration: 300 sec (5 min)
- No of requests/sampler in Test Plan: Unknown, assuming it 1
JMeter Execution:
JMeter will kick off those 1100 virtual users in 60 seconds according to the ramp-up time. So, (1100/60)~ 18 users will be active in every second for the first minute of your test. Each thread/user will execute the requests or samplers you have defined in your test plan hierarchy. As you have defined the loop count to infinite, each thread will execute the requests repeatedly until the test finishes. After 60 seconds, all of your 1100 users will be actively hitting those samplers/requests for the remaining 4 mins.
So the total number of requests you will be able to make through JMeter depends on your application response time.
If the avg response time of your requests is 1 second (assuming you have only 1 requests in your test plan), then you will be able to hit total 264000 (264000/240 = 1100 requests per second) for the last 4 mins (when all of your 1100 users are active) of your tests. You can also verify this accordingly by using Active Threads Over Time and Hits Per Second listeners.
So, Please double check the avg response time of your application or the requests/samplers you are using in your test plan.
If you want to control JMeter's throughput to 1100 per minute, you can use a Constant Throughput Timer at your test plan level and use target throughput value as 1100.
Do not forget to add the count of ramp-down time in your test duration. Yes, when you ramp up i.e. in the first minute generally you get more requests as threads are starting. In your case, your test duration should be 7 mins (60 seconds for the ramp-up 1100 users + 300 seconds for 5500 requests + 60 seconds for the ramp down for 1100 users).
You can also check this thread for more : How should I calculate Ramp-up time in Jmeter.
Please note- The total number of requests is related to throughput, Whereas the number of active threads performing the same activity is related to concurrency.
I am trying to send 1100 requests per minutes to my API endpoint for a period of 5 minutes, so in total I will make 5500 requests to the endpoint.
I don't know how you came with this 5500 number but this is not very correct.
Your setup means that:
JMeter will add 18 virtual users each second for 60 seconds
After 60 seconds pass JMeter will run 1100 users for another 4 minutes
The total number of requests JMeter will be able to make will mostly depend on application response time.
If you want to limit JMeter's throughput to 1100 requests per minute consider using Constant Throughput Timer or Precise Throughput Timer
If you don't want to limit JMeter's throughput but want 5500 executions either:
Set "Loop Count" to 5 (but in that case you might fail to get 1100 concurrent users)
Or use Throughput Controller in Total Executions mode so JMeter would stop after executing 5500 requests
I am trying to find out throughput of an endpoint using Apache Jmeter as testing tool.
I need to hit the endpoint at n threads(users) per second, and every thread should fire exactly one requests(sample).
For the above i configured bzm - Concurrency Thread Group.
Configuration One:
Target Concurrency: 100
Ramp Up Time(sec): 1
Ramp-up Steps Count: 1
Hold Target Rate Time(sec): 10
Configuration Two:
Target Concurrency: 1000
Ramp Up Time(sec): 5
Ramp-up Steps Count: 5
Hold Target Rate Time(sec): 60
What i expect is
a. Configuration One: only 1000 request must be fired in 10 sec.
b. Configuration Two: 60000 requests must be fired in 60 sec i.e 1000/sec.
As per your test case and test duration settings, I think, you are making confusion with the Threads and Requests.
Threads are virtual users. Threads and Requests aren't the same.
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.
You can achieve your requirements by using Constant Throughput Timer at your test plan level.
Constant Throughput timer allows you to maintain the throughput of your server (requests/sec). Constant Throughput Timer is only capable of pausing JMeter threads in order to slow them down to reach the target throughput. Also, it works only on a minute level so you need to properly calculate the ramp-up period and let your test run long enough.
Here are the workarounds:
Calculate the number of threads you need to achieve your target throughputs. Formula is:
RPS * max response time in second
Use the Ramp-up periods for the threads to active accordingly.
Make the loop count value to Forever
Set the test duration accordingly.
As Constant Throughput Timer works on a minute level, to achieve X RPS you have to configure your "Target Throughput" value to X*60/min and "Calculate Throughput based on" value as "All active threads".
For example, if you need 1000 RPS, then "Target Throughput" value should be 60000/min in Constant Throughput Timer.
Check out my answers on these threads to understand your scenario more briefly.
How should I calculate Ramp-up time in Jmeter
Struggling to maintain Requests per Second (RPS)?
Hope this helps!
I am using Jmeter 4.0 with Throughput Shaping Timer and I have mentioned my configuration as follows:
bzm - Concurrency Thread Group:
Target Concurrency 1000
ramp up time : 1
ramp up steps: 1
Hold Target Rate: 100 min
jp#gc - Throughput Shaping Timer
Start RPS: 333 || End Rps: 333 || Duration(sec): 1200
Since the test duration is mentioned as 1200 seconds and Rps is 333/sec so number of request hits through the test should be (333*1200) = 399600. But actual number of hits coming in range of 400000 - 410000 Requests per second.
How can Throughput Shaping Timer be restricted to not send extra requests?
Your Total test duration isn't 1200 seconds. Looking into your Concurrency Thread Group Configurations, your test duration is exactly 6001 seconds (Ramp up for 1000 user is 1 sec and the Hold Target Rate time is 6000 seconds).
To get your desired RPS, You have to follow the below formula to define the number of threads in Concurrency Thread Groups:
Threads pool size can be calculated like RPS * <max response time> / 1000
If your response time is 1 second, then 333 Threads are enough to achieve this RPS. You have used more threads in this case I guess.
According to your given test plan, it is working like 1000 users are active in 1 second and then they will try to achieve 333 RPS for 1200 seconds and then they will maintain 1000 users requests for remaining time (6001-1220=4801 seconds) as you mentioned 1000 users will hold the load for 100 mins. For this reason, you are getting extra requests than desired.
So, Define number of threads and ramp up time accordingly in your Thread groups and also sync your test duration properly (in this case hold load time could be 20 mins not 100 mins).
JMeter is not capable of immediately stopping 1000 threads when the Throughput Shaping Timer reaches its duration limit, JMeter "tells" threads to stop one 1200 seconds pass and it might take a while to gracefully shut the threads down.
Given your setup the only way of having exactly 399600 samplers is using Throughput Controller in Total Executions mode like:
This way you will get confidence that not more than 339600 samplers will be executed (the number can be less by the way if your application response time will be higher than 300 ms)
I have set the number of threads and ramp-up time to 1/1 and I am iterating my 1000 records from data.csv for 1800 seconds.
Now given the numbers, I have set the CTT, constant time throughput to 2000 every minute and I expected the average throughput to be 2000/60 = 33.3/sec, but I get 18.7/sec, when I increased the throughput to 4000/60, I still get 18 or 19/sec.
Constant Throughput Timer cannot force threads to execute faster, it can only pause threads to limit JMeter's throughput to the defined value.
Each JMeter thread executes samplers as fast as it can, however next iteration won't start until previous is finished so given you use 1 thread - the throughput won't be higher than application response time.
Also be aware that Constant Throughput Timer is accurate enough on minute level so you can rather manipulate "requests per minute" rather than "requests per second", if your test is shorter than 1 minute - consider using Throughput Shaping Timer
So I would recommend increasing the number of virtual users to i.e. 50.
See How to use JMeter's Constant Throughput Timer for more details.
I guess your application average response time is around 50ms. Which means a single thread can only perform about 20 hits/sec (1 sec / 0.05 sec per hit = 20 hits/sec).
You have 2 solutions:
increase the number of threads to parallelize requests sent,
or make you app response faster (obviously harder).
At some point, when you application can't handle more load, you should see the hits/sec dropping and the average response time increase.
The graph below shows you an example of application which has a steady response time with up to 20 concurrent threads.
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.