I want to test JMeter with 100 concurrent users and for 1 hour with 1 request in HTTP request.
PFB configuration of JMeter.
No of threads-100
rampup-1
loopcount fore ever
scheduler
start time-2015/11/26 10:36:00
end time-2015/11/26 11:36:00
duration(secs)-3600
startup delay-0
Whether JMeter hit all 100 users in concurrent . or else I need to change any configuration.
PFA images for additional details.
HTTP request
It's not clear in your question that what problem are you facing, So please be more specific.Let me guess about your problem.
Concurrency means "All the users are doing the different activity at the same time".
Do not get confused by the term between "Concurrent users" and "Simultaneous Users".These two are not the same.
Simulations users mean all the users are doing the same activity at the same time.
To clear the concept about "Concurrency" and "Simultaneity" you should go through this article.
So if you want to reach concurrency for those 100 users it will depend on your Test Scripts too.
In above test 100 Threads will be concurrent when the Ramp up time=1 second is reached.
If you want to monitor concurrent users at any given time, you should use Active Threads Over Time listener.
Related
While understanding concept of Concurrent thread and ultimate thread group, i am confused to understand result of summary/aggregate report while running concurrent thread or ultimate thread group .For example if i have 200 user and ramp up time 60 sec then i didn't see all sampler request as 200 sample after completing execution successfully but only few sampler request have 200 sample. when i use normal thread group then i always got thread count same for each sampler request after completing execution .
for realistic load testing with more user , could you please suggest me which thread group should prefer.
Could you please provide valuable guidance with some valuable link/book and also share me standard performance bench mark criteria or key parameter detail while doing load testing.(if any bench load parameter value does not meet standard then we can say that there is a performance issue)
Thanks for giving valuable time in advance.
Thanks
amit
This is due to the fact that:
Your application response time is too high
Your test duration is too low
For example I can see response times > 80 seconds:
it means that if a single virtual user has cumulative response time for 2 samplers > 160 seconds and the test duration is 120 seconds it will not be able to execute all the requests. Just increase your test duration to be i.e. 10 minutes and you should see more virtual users capable of executing all the Samplers you defined in the test plan.
Also given first user is capable of executing all the requests successfully and in time it looks like that your application gets overloaded hence cannot respond fast enough when the number of concurrent users reaches some "critical threshold", you can add listeners like Active Threads Over Time and Response Times vs Threads, this way you will be able to correlate increasing load with the increasing response time.
If also makes sense to collect:
Baseline health metrics of your application (CPU, RAM, Network, Disk usage, etc.), it can be done using JMeter PerfMon Plugin.
Lower level details like slowest methods, largest objects, heaviest database queries, etc. This form of information can be obtained using profiling tools specific to your application programming language(s).
I have the following
but when I run this with 60 threads I don't see the threads being fired off every second. Instead it seems like the requests in the transaction controller are fired off at a rate of 60 requests per min.
Is there a way I can have JMeter create threads at the rate of 60 per minute without a limit on requests?
You need to use Rampup duration in that case. Again that is one time activity, once threads are created they will execute the request and will die / repeat if you need.
Ultimate Threadgroup plugin is also helpful here.
Generally everybody is interested how much throughput(req per unit time) can server take. So in your case its doing correct job i.e. sending requests 60 per sec.
In practice creating multiple threads per sec is bad practice and IMO such testing is not useful (Why it is required?) because client threads in JMeter is not important but requests sent to server by threads (can be 1-10 or 100) many times and how server responds is important.
If your use case is different then share it in detail and we'll discuss. Hope this helps.
If you want JMeter to kick off one thread per second you need to specify Ramp-Up Period equal to the number of threads (virtual users) under Thread Group, if you want 60 virtual users - go for 60 seconds ramp-up.
Also make sure you allow your Thread Group to loop forever as if you don't - you will run into a situation when some threads have already done their job and some haven't been started yet.
Example configuration:
Example output:
More information: JMeter Ramp-Up - The Ultimate Guide
I'm using Jmeter to load test an application.
No: of threads is 100.
First HTTP request is the home page.
Second HTTP request is login page where the actual login is made
.
.
n APIs are there.
and what I want to achieve is:
First 100 threads hit the home page concurrently.
Then 100 threads hit the login page concurrently.
.
.
Then 100 threads hit the nth API concurrently.
Add Synchronizing Timer as a child of each request which you need to execute "concurrently"
Set Number of Simultaneous Users to Group by to be equal to the number of concurrent users, in your case 100
Reference: Using the JMeter Synchronizing Timer
Although above approach answers your question better scenario would be starting with 1 virtual user and gradually increase the load, in this case you will be able to correlate increasing load with performance metrics like Response Time, Transactions Per Second, resources consumption of the application under test, etc. as the situation when 100 users open login page and then hit "Login" button at exactly the same moment is highly unlikely to happen and well-behaved load test needs to represent real usage of the application by real users as close as possible.
Threads number 100 ,You need to put each request with synchronizing timer under 3 controllers, See tutorial
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"
I have made some PHP scripts and I want to test the response time for simultaneous users in JMeter. This scripts are run in a very short time (50 miliseconds).
What I would like to do is to simulate a load test from 1 to 50 of users where each user (thread) repeats the request for an unlimited period. So first we will have 1 user, after 2 simultaneous users, after 3 ... and so on.
I am trying to do it but with I have is response times where it is evident that there is no simultaneous request.
With HP loaddrunner we can define number of iterations for each thread, is this possible in JMeter?
You can possibly use these 2 thread group implementations
Stepping Thread Group
Ultimate Thread Group
from Jmeter Plugins package, that let you set load-increase for you scenario as you want.
As well you can also look onto Synchronizing Timer if you want "better" concurrency - but this is rather stress-testcase than load one.