Active Thread vs Concurrent Threads - jmeter

I want 40 Active Threads, which are doing some kind of action... I have described my issue below
I am executing one of the test plans in which I am using jp#gc - Stepping thread group... In this, I have 40 concurrent users (this group will start)but when I execute this test... The ACTIVE threads are in different number (i.e less than 40).
How can I achieve 40 Concurrent and 40 Active threads?

If you need 40 concurrent active threads for a specific period of time, I would suggest you use the Ultimate Thread Group.
Here is an example:
Ultimate thread group Configuration:
Output of "Active Threads over time" Listener:
By using this, you can easily achieve 40 concurrent users at any time period.

Related

JMeter run testplan for 2 hours with a maximum number of execution per hour

I have a test plan which performs creates an item (the process is more than 500 requests organizied in transaction controllers) in the application. I want to start the testplan to create 160 items with a maximum of 80 items per hour using 5 threads( each thread will select a random creator for the item using random csv Dataset)
I am using arrival thread group like this
the 1,3 arrival per minutes comes from 160 items / 120 minutes.
Jmeter will hang when I execute as above.
How could I achieve this ?
I don't think that Arrivals Thread Group is a good choice, your arrival rate is too low so the Thread Group doesn't start any threads and fails to stop them when the "Hold Target Rate" period ends. If the Arrivals Thread Group is your strict requirement I think you need to request the fix via JMeter Plugins Support Forum
In the meantime I would suggest considering switching to Concurrency Thread Group and Throughput Shaping Timer combination, the suggested configuration and the evidence of its work are in the below image:

Why JMeter Ultimate Thread Groups create incorrect number of users?

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.

Jmeter-Thread- how to run set of user at fixed interval of time

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.

How to configure Threads in Jmeter

How to setup delay in jmeter each user Thread Group.
I am trying to run my script Thread group (users) 10,20,30 and 40 and having a delay of 2 min each in them.
How to setup these things in jmeter?
If you want to test your application with 10 users and each user will come after 2 minute delay than pass ramp up as 1200 sec in thread group
The best controller is "jp#gc - Stepping Thread Group". Why it's the best one is, If you use JMeter "Thread Group", we need to change the "Ramp-Up Period" depending on the Threads.
10 User, wee need "Ramp-Up Period" as 20 (1 users for 2 seconds =20/10) to meet you requirements .
20 user, wee need "Ramp-Up Period" as 40 (1 users for 2 seconds =40/20) to meet you requirements .
........etc
If you use "jp#gc - Stepping Thread Group" , we no need to change the "Ramp-Up Period" depending on Thread count.
Just mention "Next, add" :1 threads every 2 seconds,"jp#gc - Stepping Thread Group" will take care Ramp-up irrespective of Thread Count.
You can use Stepping Thread to make your load testing, which helps you to simulate as an apllication used in real time
Just add Constant Timer to your thread group. That's how it is described: "If you want to have each thread pause for the same amount of time between requests, use this timer.".
And if you want to reproduce a special case when you run 30 threads then make a break for 2 mins before next 40 users, then enable "Run thread groups consecutively" option in your test plan settings (top-level element) and add thread with only constant timer between them.
For example if you want to test 40 uesr test with rampup of 10 users.
Each user will take 2 min to rampup. We can use following configuration.

Test Duration when we execute JMeter Test with 1 user and more

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"

Resources