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
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
I want to understand the relation between Stepping up Thread Groups and Number of Samples.
Stepping Thread Group
My Test Plan looks like this:
Test Plan
But in the Summary report I am getting #Samples more than 10 for certain Requests. Not able to understand how is it working.
The actual number of Sample Results will not necessarily be 10 as:
JMeter starts 1 thread each 2 second until the number of threads will be 10
Once started thread starts executing Samplers upside down
When thread finishes executing Samplers and 60 seconds of duration has not yet passed the threads starts over
So the actual number of Samplers which will be executed in 60 seconds by 10 threads will depend mostly on your application response time.
Check out What is the Relationship Between Users and Hits Per Second? article to learn more about correlation of number of virtual users and delivered load
I'm having a question about how the requests are processed,
For example:
I have created a test plan, with one thread group.
Set number of users (thread): 10
Ramp-up period: 20
Loop count: Forever
Within this thread group I have created 5 HTTP requests.
When I hit start, I understand that it starts with 1 user, and by 20th second it will have all 10 users.
Does each sampler (http request) get assigned to 1 user? Is each sampler fired in sequential order? Does it fire parallel requests? I am trying to understand overall working.
JMeter starts threads (virtual users) within the bound of the ramp-up period. In your case JMeter starts with 1 user and adds another user each 2 seconds.
When thread (virtual user) is started it starts executing Samplers upside down (or according to Logic Controllers)
When there are no more samplers left to execute the thread starts over (if the number of loops is > 1), otherwise it is shut down.
With regards to concurrency, it mainly depends on the number of threads and application response time, you can observe how many virtual users were online using Active Threads Over Time listener and the delivered load using Server Hits Per Second. The aforementioned listeners can be installed using JMeter Plugins Manager
Each thread is sequential firing HTTP requests based on your flow
But you are executing 10 threads/users in parallel, so the order of the requests in total isn't sequential, but parallel
If you defined loop count as 1, then each sampler (http request) would get assigned to 1 user,
But you are looping endlessly, so samplers can be executed more than once per user/thread
About Loop Count: (asked in comment)
Loop Count - the number of iterations for each Thread.
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.