We are using the JMETER 5.2.1 tool from GUI, for our performance tests and this if my first time using it.
I would like to simulate a 24 hours run of our service, when I have 30,000 agents registered and each one send 10 queries a day (300,000 queries a day in total).
For that purpose, I have defined a Thread Group with the following configuration:
Number of Threads: 30,000
Ramp-up period: 40,000
Loop count: 10
Duration: 86,400 (24 hours)
For some reason the JMETER run finishes after 11 hours only!
I don't understand why because as you can see I have set the Duration to be 24 hours.
Any suggestions?
If you want your test to run for 24 hours - set Loop count at Thread Group level to Forever or to -1
If you want to execute 300 000 queries in 24 hours you need to introduce a rate limiting on JMeter side to execute 208.4 requests per minute, it can be done using i.e. Constant Throughput Timer
Don't use GUI to run JMeter tests as it might have very negative impact on test results, JMeter GUI is only for tests development and debugging, when it comes to test execution - go for command-line non-GUI mode
If Loop Count is not -1 or Forever, duration will be min(Duration, Loop Count * iteration duration) according to Scheduler Configuration in JMeter GUI. In other words you did 10 Loops faster then 24h. So you can run your loop Forever and limit it by 24h - you did more loops or you can try to add delay to your loop to match 10 loops in 24h. Third option is 3rd party plugin Constant throughput timer.
I would redesign your test to 10 Threads, 300 Ramp-up, Loop Forever, Duration 24h and tweak delay in Loop to match (24*60*60)/300000=0.288tps Since I understand threads as Concurrent connections at the same time (not 24h as you do)
Related
I am curious why the elapsed time of the current running test in JMeter is not accurate?
I set my thread group to the following specs:
Number of threads - 2;
Ramp-up period - 1;
Loop count - 60
I suppose that means that every second 2 users will perform some actions and the step will be repeated 60 times. Which means it will take 60 seconds to complete the test.
But the elapsed time of the current running test shows 25 seconds. Why it's less than 60 seconds? How can it be that my test is completed so fast?
JMeter acts as follows:
Each thread (virtual user) starts executing Samplers upside down (or according to the logic controllers) as fast as it can
When there are no more Samplers to execute (or loops to iterate) the Thread is being shut down
Your configuration means that 2 users will execute samplers 60 times, the elapsed time depends on:
how fast JMeter can send the requests
how fast your application can respond
If you're looking for a configuration where 2 threads are executing samplers for 60 seconds - amend your Thread Group setup as follows:
If you have troubles in setting up the workload model it might be easier to use a Custom Thread Group for example Ultimate Thread Group which provides extreme flexibility when it comes to ramp-up, ramp-down, time to hold the load definition, etc.
These "custom thread groups" can be installed using JMeter Plugins Manager
The requests inside your test will be executed 60 times using 2 concurrent users
For example if you have 1 request which takes 1 second it will take around 30 seconds:
Total 60 requests * 1 seconds (time per request) / 2 (concurrent) users = 30 seconds
As the title says.
What does Jmeters thread group duration exactly mean?
In my case.
The settings are:
100 threads
1 loop count
and 30 seconds thread duration.
Does this mean, every thread gets 30 seconds and if it takes longer we get an 5xx Error?
Or is the duration for the whole thread group. which means if 30 seconds are over, the test fails?
Duration means that after 30 seconds all threads will receive "shut down" signal.
JMeter acts as follows:
All threads are being started within the ramp-up period
Once started threads start executing Samplers upside down (or according to Logic Controllers)
Threads will execute Samplers that many times as you have "Loops" defined
When:
there are no more Samplers to execute
no loops to iterate
Duration is exceeded
the threads will be shut down
In your case JMeter will start executing samplers 1 time each and if you have a lot of samplers under the Thread Group and 30 seconds pass - the threads will stop where they're at the moment. If you don't have enough Samplers you won't be able to achieve 100 virtual users concurrency as some threads will finish third work and the others won't be yet started. More information: JMeter Test Results: Why the Actual Users Number is Lower than Expected
You can observe the actual delivered load using i.e. Active Threads Over Time chart
When you need to run JMeter tests for specific amount for time (e.g 30 seconds), set the Loop Count to infinite by checking the infinite checkbox and set the duration of the test in seconds in Duration input as shown below.
Once the duration is over test execution will stop gracefully.
It will not send new requests after the duration, but it will wait for the test results of the already initiated requests.
JMeter Thread Group documentation
I have created a set and just confused with the Loop Count and Ramp Up period.
I have a test set with the following parameters.
Threads = 30
Ramp Up Period = 30
Loop Count = 100
As per the page on
quora.
I suppose:
a) If Loop count is Zero, then each of the 30 threads will be starting every second. As per the shared the web page, I guess 30/30 * 100 ie 100 threads/requests will be hitting the server every second. Please correct me if I am wrong.
b) As per the above parameters, there will be a total of 30 * 100 threads/requests. Does this mean all the 3000 threads/requests will be sent within 30 seconds [ Ramp Up period ]
Assuming you have 30 users and 30 seconds ramp-up
JMeter will start each virtual user each second
Each virtual user will start executing samplers upside down (or according to the logic controllers, if any) as fast as it can (if you don't use timers) so the delivered load can be either more or less than 30 requests/second, it depends on how fast JMeter is executing requests and on your application response time as JMeter will wait for response from previous sampler before starting new one
When virtual user finishes executing all the samplers defined in test plan it will start over and do point 2 for 99 more iterations
When virtual user won't have more samplers to execute and loops to iterate it will shut down
A couple of tips:
You can use Server Hits Per Second listener to see how many requests per second you are actually making given your test plan configuration
You can control the number of requests per second via Constant Throughput Timer
Consider upgrading to JMeter 3.2 as newer JMeter versions normally contain new features, performance improvements and bug fixes
according to jmeter manual ramp up is:
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.
So if your goal is to reach 3000 request within 30 seconds the above wont do, it might take more than that depending on how much it takes to finish the requests you are sending.
If you are looking for Throughput you can add an aggregate report listener which calculates the throughput for you and depending on the results you can configure your thread properties to reach your goal.
Reference :
Jmeter user manual
I have to test ramping up 1 user every minute for 10 minutes and then then ramping up 20 users ever minutes for next 10 minutes with jmeter. I tried to search on internet, seems like I need to use ultimate thread? If so can someone please give me an example of above scenario?
You can use multiple regular thread groups and in Test Plan,you can select Run thread Group consecutively.
Ultimate Thread plugin allows fine grained control of user threads. It will certainly achieve the concurrency pattern you're looking for. You can also start a thread group delayed with just out-of-the-box Jmeter though:
Use 2 thread groups, and set the required ramp up rates for each thread group. Since you need the second thread group to kick in 10 minutes after the test starts, add a startup delay of 600 seconds.
The relevant jmeter documentation is in Section 4.1 here:
Version 1.9 introduces a test run scheduler. Click the checkbox at the bottom of the Thread Group panel to reveal extra fields in which you can enter the start and end times of the run. When the test is started, JMeter will wait if necessary until the start-time has been reached. At the end of each cycle, JMeter checks if the end-time has been reached, and if so, the run is stopped, otherwise the test is allowed to continue until the iteration limit is reached.
Alternatively, one can use the relative delay and duration fields. Note that delay overrides start-time, and duration over-rides end-time.
It is possible to do with 1 ultimate thread group.
Your setup should be as given below. You did not mention the test duration. I assumed it as 3600 seconds.
1st Row : We will have 10 threads in 600 seconds by starting a thread every min.
2nd Row: We will have additional 200 threads (ignoring the first 10 threads), in the next 600 seconds by starting 20 threads every 1 min.
We need a wait for 600 seconds in the second row which is update in Initial Delay field for the first row to complete.
I am running my load test for a duration of 1 hour,in between the test I want a scenario to run for a duration of 1 minutes at regular interval of 15 minutes.
In jmeter,currently I am able to simulate for all the others scenarios except for the burst mode.
How do I keep the delay for 15 minutes and trigger the request for duration of 1 min?
How do I achieve the TPS for the burst? Currently I have to manually trigger jmeter script.
I would suggest doing the following:
Add a separate Thread Group.
Configure ramp-up and thread count as required.
Add a Constant Timer, set Thread Delay to 900 000 (15 minutes = 900 seconds, 1 second = 1000 ms)
Add a Runtime Controller, set Runtime to 60.
Add a Loop Controller, set Loop Count to Forever.
Place your burst test logic under the Loop Controller.
If you need to define requests per second rate during spikes use Constant Throughput Timer
I came here since I had the same issue or similar issue of "simulating" burst like request during the load test. I tried to follow the accepted answer but didn't get it to work (perhaps I misunderstood some steps), anyway; I based my solution in #esteveavi comment Loadtesting in burst mode in Jmeter from the original post above. And ended up using JMeter's "Ultimate Threat-Group" plugin with something like the following test plan set up: