Here is my test plan configuration:
Number of Threads (users): 150
Ramp-up Period (in seconds): 10
Loop Count : Forever
Scheduler: 300 Seconds
I ran the test with the duration of 300 seconds. After loading the jtl file, The number of samples shown in summary report is 7435.
I ran another test with configuration
Number of Threads (users): 300
Ramp-up Period (in seconds): 10
Loop Count : Forever
Scheduler: 300 Seconds
but the samples count showing in summary report is 7530.
I tried to compute but I can't understand how it came up with that many sample.
If Ramp-up Period is the time taken by JMeter to create the number of threads per iteration and if the duration of the test is 300 seconds, then I should have 4500 samples only for first run and 9000 for second run. I do not know how or if Loop Count affects this.
Please, correct me if I'm wrong. But JMeter will not execute sampler once. Samplers will be repeated forever (till scheduler reached value of 300 seconds).
Related
I need to test an application can handle 500 users over the space on 1 hour. How long should I set the ramp up period for the specified amount of time and users?
It depends on what you're trying to achieve. There are no "strict" rules, no recommendations either.
As per 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.
So you can use 500 as ramp-up so all 500 users will be online in 500 seconds.
Other option is to set ramp-up period for 1st 30 minutes and next 30 minutes keep the load of 500 users.
The idea is to add users gradually so you could correlate increasing load with other metrics and KPIs like response time, number of transactions per second, number of errors, etc. so you could state where is the saturation point, where is the first bottleneck, etc.
More information: JMeter Ramp-Up Period: The Ultimate Guide
The ramp-up period, Is the time needed to start all the threads defined.
So, If you add 3600 with 500 Thread, This will mean a new thread will be launched every 7.2 seoconds, And the last one will start after 1h ( 3600 seconds)
If this is what you want, you can set Ramp up to 3600.
quote from official doc
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.
Running JMeter version 5.4.1
I have the following setup for a JMeter thread group:
Number of Threads: 300
Ramp-up Period: 300 seconds
Loop count: infinite
Specify Thread Life time: Duration 600 seconds, startup delay: 0
Thread group is set to continue after a sample error.
So with the above setup, I'm expecting the test to spin up 1 thread per second, when it reaches 300(5min) seconds, it will have a full 300 threads running. Each thread should be running for 600 seconds(10min) before stopping. I'm expecting the total run time to be 900 seconds (Last thread starts at minute 5 + 10 min run time = 15min).
But the actual behavior is different and I can't figure out why.
Actual behavior:
--300 threads spin up after 300 seconds, 1 thread per second. Cool this is what I'm expecting.
--at 600 second mark, the first thread start to die. Cool so far so good
--at 12min which is 720 seconds, ALL threads have died off, and the test is complete... umm.. what happened here? I was expecting a full 300 seconds wind down time, not 120 seconds?
As a result, the full test finished at 720 seconds (12min), instead of the full 900 seconds (15min).
Can anyone explain to me what is going on here?
You have to configure your test duration accordingly.
In your case, the test finishes at 600 seconds. The last 120 seconds was the ramp-down time of those active threads. You can observe it through Active Threads Over Time Listener.
Your total test duration would be like warm-up period + hold load activity + warm-down period. i.e (300+600+300)= 1200 seconds or 20 mins.
300 threads will be active in 300 seconds, then all the 300 threads will hit requests to the server for 600 seconds, and then those 300 threads will be down in the next 300 seconds.
You can also use Ultimate Thread Group like this as well for a better understanding of your test, where the warm-down period is used as 120 seconds, so the total duration of the test is (5+10+2)=17 mins or 1020 seconds.
It isn't exact and specify duration of the test plus finishing iteartion
This denotes the total duration of the test. One disadvantage to run the test by specifying the duration value is that the test stops immediately when the test duration is completed; without completing the loop (iteration) due to which you could see some differences in transaction count.
You specified test duration of 600 seconds, why do you expect your test to last longer?
Once 600 seconds are passed JMeter will ask threads to stop and the time required for all of them to stop mainly depends on the nature of the test, request/response size, etc. In ideal conditions the test should be stopped immediately.
So if you want your test to run 15 minutes - set duration to 900 seconds.
If you want the gradual ramp-down - consider adding a Timer to your Test plan or switch to a custom thread group which allows precise control over threads, see How to Ramp Down in JMeter article for more details.
Coming back to threads termination taking 2 minutes, it should not be the case, make sure to run your JMeter test in command-line non-GUI mode and follow other JMeter Best Practices
This is with respect to Jmeter's loop count behavior.
Number of threads 4000
ramp up period 800
Thread count 2
Action to be taken after a sample error Continue
Same user on each iteration Yes
Delay thread creation until needed Yes
This is resulting in 8000 requests being made in 800 seconds. However, my use case is, 4000 requests in 800 seconds (count=1), then another 4000 in next 800 seconds (count=2).
What changes can I make for this?
Ramp-up period doesn't mean 8000 requests in 800 seconds, it results in:
JMeter starts with 1 virtual user and adds 5 virtual users each second for 800 seconds
Each virtual user executes Samplers upside down for the specified number of iterations
When there are no more Samplers to execute and loops to iterate the thread is being shut down
My expectation is that you only have 1 Sampler and its response time is relatively low (less than 1 second), you can check the actual amount of virtual users and produced load using Active Threads Over Time and Transactions Per Second listeners
If you need to implement 4000 requests for 800 seconds twice the easiest option would be going for the Throughput Shaping Timer and configuring it to reach/maintain 5 requests per second throughput for 800 seconds twice with 10 seconds time frame of doing nothing between loops.
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)
My performance test strategy is to use JMeter to send 3 different requests to a linux server continually. They are Init, Calculate and Apply.
The number of active users of peak hour is 40 and the number of each request per hour is 200. The load test should be conducted with the peak usage with no less than one hour.
If my understanding is correct, running the test for two hours eventually there will be 1200 samples shown in the result table (200 requests * 3 * 2 hours). However, with the following configuration there are much more samples sent to the server.
Thread Group:
- Number of threads: 200
- Ramp-up time: 3600 seconds
- Duration: 7200 seconds
I have also tried setting the number of threads 50, the result is still far more than my expectation.
May I know how to configure the JMeter correctly ?
Your configuration should be:
Number of threads : 40
Ramp-up time: Should be short in your case, its value tells in how much time threads will go from 0 to 40.
Duration is ok
Finally, as you want 200 requests per hour, which would be 600 for the 3 ones, it would be 10 per minute, you need to use Constant Throughput Timer inside a Test Action:
Where Test Action is :