Example:
`1. No of Threads = 100
Ramp-up time = 20, means every 1 second = 5 requests will be processed.
Loop Count =1
In the same time:
If i will do like below
No of Threads = 100
Ramp-up time = 1,
Loop Count =1`
And put Synchronization Timer : No of Simulated user to group = 5.
In this case as well, J meter process 5 requests at one time.
So what is the different logic between the above 2 concepts.
Considering case 1 where the
Number of threads = 100, Ramp-up time = 20 and loop count =1.
This means that for every one sec 5 threads will be induced.
Depending on the time taken for the response the test will run for at least 20 sec or more.
Considering case 2 where the
Number of threads = 100, Ramp-up=1, loop count=1 and
Adding Synchronization Timer with No of Simulated user to group = 5
A batch of 5 users will be added at once.
Both the tests don't take the same amount of time to complete.
In case 1, 5 users are distributed over a period of one sec. i.e. per 0.2 sec one user is added.
In case 2, 5 users are added to the active thread in one go.
To know more about Synchronizing Timer
To best understand the difference between the 2 use cases, increase the number of threads to 200 while keeping the remaining parameters as is. Then the difference can be noticed easily.
means every 1 second = 5 requests will be processed. Loop Count =1 - this is wrong, JMeter will start 5 threads each second, the processing time depends on application response time. The concurrency (number of requests at the same moment of time) is not guaranteed
A quote from JMeter documentation:
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.
Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen).
Start with Ramp-up = number of threads and adjust up or down as needed.
See JMeter Ramp-Up - The Ultimate Guide article for more comprehensive explanation.
Synchronizing Timer guarantees that 5 requests will be executed at the same moment so in your 2nd scenario it would be sending requests in "batches" of 5. Normally people go for Synchronizing Timer to do some form of Spike Testing
Related
I ran a test plan with 5 users for a total of 20 seconds and what I am not able to understand is what ramp-up period is in actual. Does it means that each user will get 4 seconds or 20 seconds will be used in total for 5 users?
If case 1 is true(4 second for each user) then the first thread should be completed in 4 seconds but it took 6 seconds to complete it and still the result is passed and next user gets executed? This gets much confusing. I need to clear my doubt as I am not able to find any answers from all the inputs that are available here
As per JMeter Thread Group Documentation:
Ramp-up Period
How long JMeter should take to get all the threads started. If there are 10 threads and a ramp-up time of 100 seconds, then each thread will begin 10 seconds after the previous thread started, for a total time of 100 seconds to get the test fully up to speed.
You have 5 users
if you set ramp-up period to 0 - all 5 users will start at once
if you set ramp-up period to 5 - JMeter will start with 1 user and will add an extra 1 user each second
if you set ramp-up period to 10 - JMeter will start with 1 user and will add an extra 1 user each 2 seconds
etc.
Once user is started it starts executing Samplers upside down (or according to Logic Controllers) when there are no more samplers to execute or loops to iterate - the thread is being shut down.
Check out JMeter Ramp-Up - The Ultimate Guide article for more information on configuring users arrival rate.
You might also be interested in Ultimate Thread Group which makes workload definition easier, moreover you will have a chart representing anticipated load. You can install Ultimate Thread Group using JMeter Plugins Manager
If you want threads not to effect test expected time then use instead Thread group's Loop Count as the number of repeatitions you need.
If you want/must use threads calculate ramp period time as
(test expected time + 1 second) * number of threads
Let's say that I have the current configuration :
Number of Threads (users): 150
Ramp-up : 30
Loop Count : None
If I add up a duration of 2 mins so :
Number of Threads (users): 150
Ramp-up : 30
Loop Count : None
Duration (minutes) : 2
How does Jmeter going to react? If each Threads take about 10 seconds to complete
Thanks in advance
Both Loop Count and Duration (if both present) are taken into account, whichever comes first. So in first configuration, you are not limiting loop count or duration, so the script will run "forever". In second case, loop count is still not limited, but duration is. So the test will stop 2 minutes after startup of the very first user, and the time includes ramp-up time. Stopping includes not running new samplers, and hard stop for all running samplers.
In your case, 150 users will finish starting after 30 sec. That means the first thread to run will complete 3 iterations (x10 sec) by the time the last thread just started its first.
Within the remaining 90 sec, all threads will complete roughly 8-9 iterations.
So for the first thread you should expect 11-12 iterations, for the very last thread to start, 8-9 iterations. Remaining threads anywhere between those numbers. Assuming ~30 threads executed same number of iterations, between 8 and 12, you get roughly 1500 iterations in total (could be a little over or under). Last iteration of each thread may be incomplete (e.g. some samplers did not get to run before test ran out of time).
Generally, since duration may leave unfinished iterations, I think it's only good as a fall back or threshold in pipeline automation. For example: run is configured to complete 1000 iterations (should take about 16 min if iteration takes 10 sec). So duration is set to 24 min (gives about 50% slack). It won't be needed if performance is decent, but if execution takes extremely long, we may hard stop it at 24 min, since there's no point to continue: we already know something is wrong.
Whats the difference in JMeter between:
(a) 50 threads 5 second ramp up and 1 loop count
(b) 10 threads 1 second ramp up and 5 loop count
For me (a) and (b) seem to be the same thing, 10 threads will be instantiated every second for a total of 5 seconds.
Am I missing something here?
ramp-up period doesn't effect total number of threads. see user manual:
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen
So both scenarios will be executed 50 times, the difference is the order of the threads. In your case let's assume each thread takes ~5 minutes
Scenario a (without encountering any bottleneck) will take ~5 minutes (+5 seconds ramp up)
While Scenario b will take approximately 5 times more because each loop will start after threads ends. 5 minutes will take for each loop - ~25 minutes (+1 second ramp up)
Also you can have limitation on your server that doesn't allow 50 threads executing in 5 seconds same operation so Scenario a will be impossible to execute.
How to test 1 million users in Jmeter concurrently ? What should I use Number of threads & Ramp up period ?
I tried but I given Number of threads 1000000 and I have to give Ramp up period which don't allow to test in concurrent .
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.
Ramp-up needs to be long enough to avoid too large a work-load at the
start of a test, and short enough that the last threads start running
before the first ones finish (unless one wants that to happen).
Start with Ramp-up = number of threads and adjust up or down as
needed.
if you want all your threads starts simultaneously you can to set a ramp-up = 1 this means that jmeter will take 1 second to get all threads up and running! or 0 to starts them asap. but i hope that you have a good hardware to supports this.
http://jmeter.apache.org/usermanual/test_plan.html
Actually I would recommend choosing ramp-up so the load will increase gradually. For instance, your application is able to serve 500k users without any lag, from 500k to 700k response time grows, at 750k concurrent users it dies.
If you release all 1M users at once you won't get above information, all you will know is that your application doesn't support 1M users.
So I would recommend increasing loops count so existing users could continue work while new users are arriving so you will have gradually increasing load up to 1M of concurrent virtual users
Define desired test duration using "Scheduler" option in Thread Group (or using Runtime Controller)
Set "Loop Count" to Forever or put -1 there.
Set your ramp-up phase to be something between 20% and 50% of the overall test duration
Optionally it would be also good to implement "ramp-down" to see the system under test behavior when the load gets back to normal
Also keep in mind the following:
JMeter default settings are good enough for tests development and debugging, you will need to tweak them to achieve the maximum performance. Check out 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure guide for JMeter performance tuning recommendations
It is highly unlikely that you won't be able to simulate 1M of users using single machine so consider setting up Distributed JMeter architecture
1,000,000 threads would get you 1,000,000 Transactions Per Second only if the Response Times were under 1 second. You will need enough threads to include the system response time. 10,000,000 threads would allow for up to 10 second Response Times.
Others are correct, ramp up slowly to the full rate in order to have the time to view where issues lie.
I would use these settings to begin sizing the lab and slave count:
Number of Threads: 10,000,000
Ramp-Up Period: 1800 sec (30 mins)
Loop: Forever
Throughput Shaping Timer:
- Start RPS Row 1: 1
- End RPS Row 1: 1,000,000
- Duration Row 1: 1800 (same as rampup)
Start RPS Row 2: 1,000,000
End RPS Row 2: 1,000,000
Duration Row 2: 600 (10 minutes at full rate)
Start RPS Row 3: 1,000,000
End RPS Row 3: 1
Duration Row 3: 600 (gradually backing threads off to check for resource recovery)
Note what resource runs out first, adjust and repeat.
I want to run a JMeter test with a number of concurrent threads with each thread sending a request every 10 seconds.
These are my thread properties.
Number of Threads: 10
Ramp-Up Period: 10
Loop Count: 1
Result: 10 requests divided over 10 seconds, so every second a request and exactly what I want.
Now I want to run this test for 3 times(30 seconds). So I set the Loop Count to 3.
But the result is: 30 requests in 10 seconds. This is strange, because I would expect to run this for 30 seconds and get 1 request per second.
How can I achieve this with JMeter?
My final goal is to run this test for a long period and also increase the Number of Threads.
How to do this with JMeter?
I researched this today and came to this conclusion: The Loop Count setting is a complete misnomer. It doesn't actually loop in any sort of chronological sense, even if your Test Plan has Run Thread Groups consecutively checked. What it does do is multiply your thread group and run all multiples concurrently. Therefore, the Ramp-Up Period is only respected once, and NOT once per "loop" - there is no temporal loop!
An explanation with graphs can be found here: http://pro-programmers.blogspot.com/2009/07/jmeter-max-threads-with-rump-up-and.html
Seems that the most simplest ways to control throughput in your tests is using either standard "out-of-box" Constant Throughput Timer or custom Throughput Shaping Timer from jmeter-plugins collection.
In both the cases structure of the test will be like the following:
Thread Group
Number of Threads = N
Ramp-up Period = N
Loop Count = 1
Constant Throughput Timer
Target Throughput = 60
Calculate Throughput based on = "all active threads in current thread group"
. . .
Loop Controller
Loop Count = M
. . .
HTTP Request
. . .
Here Loop Controller defines number of iterations.
Looks like both the timers are not absolutely precise as well as both are a bit differently configurable:
Here is also a kind of practical example how to vary the throughput.
In my experience with Jmeter if you set
Number of Threads: 10
Ramp-Up Period: 10
Loop Count: 1
you create 10 threads into 10 seconds so you create 1 thread every second.
With loop count of 1 you repeat this once.
But if you increase loop count I think that you don't create new threads but repeat jmeter elements procedure in the Thread Group therefore the time beetween the request isn't 30 seconds but just over 10s.
If you want to create 30 threads within 30 seconds you have to set
Number of Threads: 30
Ramp-Up Period: 30
Loop Count: 1
If you want to repeat 10 threads for 3 times with ramp- up of 10 seconds you should insert a Timert->Constant Timer with thread delay of 10000 ms so you obtain 30 requests in 30 seconds (really you should consider the time of executions of the task)
refer link: http://www.testingjournals.com/5-must-know-features-thread-group-jmeter/
scenario 1 :
number of threads = 20
Ramp-up period =100
loop count=1
Every 5 seconds(100/20) 1 request/thread will hit the server,Execution will start with 1 request at a time
scenario 2 :
number of threads = 20
Ramp-up period =100
loop count=4
Every 5 seconds(100/20) 4 request/thread will hit the server, once the 1st request/thread completes , it will start 2nd loop by executing same HTTP request,Execution lasts until all 20 threads executes all HTTP requests 4 times
My understanding of Ramp-Up is that a value of 0 will fire all threads at the same time (concurrently).
You might be able to achieve what you want by setting the following:
Number of Threads: 10
Ramp-Up Period: 0
Loop Count: N
and then using a Controller to determine when to end each loop.
Yup, the Loop Count parameter is not intuitive. From what I figured out it is actually the number of times the thread/user performs a particular test
So if I understand correctly your intention that you want:
to run N number of concurrent threads/users
each of them sends a request every 10 seconds
you want to run this scenario for around 30 seconds
the configuration should be the following:
Number of Threads: N
Ramp-up Period: 0
Loop Count: 3
And in Constant Throughput Timer (within the Thread Group) you should set Target Throughput (samples per minute)=6, which means request every 10 seconds