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
Related
I want to achieve the throughput 7.6 requests per second.
I am using bzm- Concurrency Thread Group with Feedback function and Throughput shaping timer as below. Please ignore the thread groups which are striked out. They are disabled and are not executed by Jmeter.
When I run the script from command line, it shows the logs as below
And in the log file, it mentions that:
In the Concurrency Thread Group, I have defined Target Concurrency with a Feedback function as ${__tstFeedback(tst-name,1,100,30)}
Here, 1 and 100 are starting threads and max allowed threads, 30 is how many spare threads to keep in thread pool.
My first question is:
Q1. Why in the command line logs it says that no free threads are available in the current thread group. As you can see from the command line, only 39 threads started. I have defined max allowed threads as 100. On the top of that 30 are kept in the thread pool so that Jmeter can use them if 100 threads are not enough. I also tried increasing the number of threads by passing ${__tstFeedback(tst-name,1,200,30)} , but still I get the same error.
Still why does it say in the logs that no free threads available and hence increase your number of threads?
Also, as you can see from the Summary report, Transaction Controller for Scenario 3 and Scenario 4 are not executed by Jmeter
Q2. What could be the reason that Scenario 3 and Scenario 4 are not executed by Jmeter?
Q1 the warning is being written in 6 milliseconds after test start when only 1 thread was running, do you really expect that 1 thread can conduct the load of 7.6 requests per second? I mean theoretically it's possible, if your application response time is below 130 ms, however I don't think it's applicable for your case, try starting with i.e. 30 threads and remove these ramp-up period and steps.
Q2 we don't know, most probably the reason is that your test doesn't run long enough so first thread isn't able to execute all samplers in scenarios 1 and 2 or there are some Logic Controllers which prevent these scenarios execution or there is a Flow Control Action sampler which doesn't allow the thread to go further, etc.
The answers are always in jmeter.log file, you might also want to increase the JMeter log level for the Throughput Shaping Timer by adding the next line to log4j2.xml file:
<Logger name="kg.apc.jmeter.timers.VariableThroughputTimer" level="debug" />
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
When I'm using the original JMeter Thread Groups and set 10 threads (users), it fires 10 external HTTP calls.
When I changed it to Ultimate Thread Groups (UTG) and set the following attributes...
Start Threads Count = 10
Initial Delay = 0
Startup Time = 60
Hold Load For = 30
Shutdown Time = 10
...it fires thousands of external HTTP calls. Even the Stepping Thread Groups (STG) and Concurrency Thread Groups (CTG) also behave the same as UTG.
Why this happens when using non-original JMeter thread groups? I'm looking for ways to create 10 users that create 1 external HTTP call each (means 10 in total for the whole test plan) using UTG, STG or CTG but I don't really understand why this happens.
Screenshots when using original Thread Group
Screenshots when using original Ultimate Thread Group
Your scenario results in:
On 5th second of the test 1st virtual users starts
Within next 55 seconds remaining 9 virtual users start
10 users are active for 30 seconds
Then each 1 second each 1 virtual user is being shut down
You're seeing much more than 10 requests because once virtual user is kicked off it starts executing Samplers as fast as it can and the actual number of executed Samplers will mostly depend on your application response time. Check out What is the Relationship Between Users and Hits Per Second? for more comprehensive explanation.
If your goal is to execute 10 requests in 1 minute 40 seconds you need to use Constant Throughput Timer or Precise Throughput Timer or Throughput Shaping Timer in order to limit JMeter to send 1 request per each 10 seconds.
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.
Hi i want to run a performance test in which i want to load say 10 users in first second and wait for 2 minutes then load next 10 set of users and again wait for 2 minutes then again 10 users in the same Test plan is it possible
For this purpose "Stepping Thread Group" is the thing you need. And to fix or control 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."Stepping Thread Group" or 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.
http://jmeter.apache.org/usermanual/component_reference.html#Constant_Throughput_Timer
If you are using JMeter, then Stepping Thread Group is what you are looking for.
Features of Stepping thread group are :
1. preview graph showing estimated load
2. initial thread group delay to combine several thread group activities
3. increase load by portions of threads (users) with ramp-up period
4. configurable hold time after all threads started
5. decrease load by portions
Following screenshot shows Stepping Thread Group set to generate load increasing by 10 users each 2 minutes:
Stepping Thread group
If you plan to increase your user/thread at a constant rate, the Stepping Thread Group helps. You can read more about it at :
http://jmeter-plugins.org/wiki/SteppingThreadGroup/
But if you plan to increase your load at a non-constant rate, for example, if your plan is -- start 10 threads in first 5 seconds, wait for 10 secs and start 5 threads, wait for 15 more secs and start 15 threads , then you can use Ultimate Thread Group.
I won't write more about Ultimate Thread Group, since I will limit myself to the question asked. If you are more interested about it, you can read it over at JMeter Plugins site.