I have 3 thread groups(3 scenarios in ultimate thread group) for one test plan where i am distributing load among those. for example 12 users i am distributing 4 users for each thread group.Here i have multiple doubts where i am expecting bit more clarification.
1) each scenario has login transaction in a flow.is it possible to make one transaction for all the scenarios?
2) it is regarding load testing where i am distributing the load with below scenario.
Total no of scenarios=3(ultimate thread groups where they contains multiple transaction controllers)
Total no of users=10
Ultimate thread group 1 scenario= 4 users(thread count)
Ultimate thread group 2 scenario= 3 users(thread count)
Ultimate thread group 3 scenario= 3 users(thread count)
ramp up=150 sec,
steady period=600 sec,
ramp down=150 sec (Total duration 15 min) configured for each thread group.
For thread group scenario 1 thread users are 4.so i can expect the transactions under that can execute 4 times randomly.
But in listener i am able to see that the transactions are executing more than 4 times(nearly 20 times that are getting executed which are fail due to lack of test data where i am providing test data foe only 4 users for this scenario).
Can any one please tell me where exactly i am doing mistake and how can i correct it myself?Please find below screen shots for reference
The Ultimate Thread Group (see: https://jmeter-plugins.org/wiki/UltimateThreadGroup/?utm_source=jmeter&utm_medium=helplink&utm_campaign=UltimateThreadGroup) runs for 15 minutes. That will mean that 4 threads will run for 15 minutes before being shutdown. So from you information I guess a typical thread runs through your scenario in about 3,75min (225s). So when that thread finishes a new one will start and run your scenario again and again, until the 15min limit is reached.
If you want to run them only once I suggest to use the basic Thread Group, with 4 threads and no looping (loop count = 1).
Related
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 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 want to run load tests for 5 different req types with different number of users for each. At a time only one type of request should be hit with its defined no of users. The test should run for 24-48 hrs.
Is this possible to do this in jmeter? I am unable to randomize the thread groups for each request type with only one running at a time.
Thread group 1 runs 10 thread per sec forever
Request 1
Thread group 2 runs 5 thread per sec forever
Request 2
Thread group 3 runs 4 thread per sec forever
Request 3
Thread group 4 runs 2 thread per sec forever
Request 4
Thread group 5 runs 1 thread per sec forever
Request 5
Thread group should run randomly and only one thread group should run at a time.
Please suggest if there is any other way to do this in jmeter.
You can not apply the logical behavior at the "Thread Group" level. That is just not possible. Also, what you need does not seem to fit in the real world scenario unless you extend my knowledge with a valid use case.
Apart from randomizing the thread group you can do everything else mentioned and when you trigger the test all the thread groups will execute.
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.
I have concerns about the duration of executing JMeter Test Scenario.
In fact, if we execute a manual test with 1 user in 1 hour, we will find the same duration or little more with 3 user.
But, with JMeter test the duration with 1 user will be multiplied by the number of users.
During my scripting with this tool, I've noticed that JMeter always wait for the response of the request to pass to another request. It's like we have 1 user doing the work of multiple users.
Does any body have explanations about this issue?
Can we configure JMeter to perform like we have x users working in // ?
Depends how you are simulating users..
Each thread will wait for a response, but users are represented by different threads, and threads do not wait for each other to complete samples, they are independent.
If you are using threads in thread group to represent users (which is the intended usage), the threads will start concurrently and run independently, so you should see the 3 users complete in an hour, as with manual tests. If this is not happening, then you should check the resources used on the client running jmeter during single thread and multi thread runs. Or perhaps the bottleneck may be in the transport (ie bandwidth). All you have determined so far is that the bottleneck is prior to the server, you need to determine where it is.
It is also possible you have created a thread group for each simulated user. If this is the case you can set the groups to run consecutive or concurrent. The setting for this is on the Test Plan element at the very top of the tree. You want concurrent, so untick 'Run Thread Groups Consecutively'.
So it comes down to how you are simulating users.
In ideal world if you test your site with 1 user all set of actions completes in 1 hour. If you add another 100 users - still one hour, 1000 users - 1 hour.
In real world server response time increases with the number of concurrent threads. But it isn't something like
1 user - average response time 10ms
2 users - 20 ms
3 users - 30 ms
But
1 user - 10 ms
2 users - 10 ms
3 users - 10 ms
10 users - 11 ms
The whole idea of the performance testing is to determine the upper limit of server load and identify bottlenecks and issues which happen under the load so you could state something like: using this hardware and this configuration the application is capable of serving 500 concurrent users without serious delays. In case of 1000 users response time will be more than 15 seconds.
In regards to threads, JMeter thread starts, executes samples one by one for defined amount of loops and exits. It is applicable for each thread which are independent. Basic throughput control can be done via ramp-up and loops count (see Thread Group documentation on details)
More advanced load scenario definition can be done using following Test Elements:
Ultimate Thread Group - which provides easy visual way of defining ramp-up, ramp-down and time to hold the load
Constant Throughput Timer - to set desired load rate in requests per minute
Synchronizing Timer - to pause all the test threads and release them at the same moment to produce a "spike"