I am trying to perform load testing on NodeJS application, the application allows single login session for an user.
But, when i tried to perform load testing with 8 concurrent users (using the same credentials) it was working.
So, i tried to create 10 user IDs and added to the CSV file and configured "CSV Data Set Config" and "HTTP Cookie Manager" and set the "Number of Threads" to 80.
When I run the test plan, the credentials are not passed to each sessions equally. for example, userID1 is passed 3 times and userID2 is passed 7 times.
Can you clarify the reason for this behaviour and how to run the threads with each credentials (8 sessions for every credentials) from csv file ?
Make sure you have set the options for CSV Data Set Config as All Threads for Sharing mode and provide a minimum ramp-up period (say 1 second) so that each thread reads the CSV lines properly without clashes.
For the question why it worked 8 concurrent sessions , where you allow only single session from UI - My guess is you used the same credentials for all 8 users - so server might have considered it to be 8 parallel requests from the same user. It depends on how session is maintained. For eg., if it was with a session-cookie , then If you had 8 different cookies it might have failed. But this is only a guess, as I don't know how its done in your app.
JMeter acts as follows:
All threads are started within the bounds of the ramp-up period which you define in the Thread Group
Each thread starts executing Samplers upside down (or according to the Logic Controllers) as fast as it can
JMeter waits for previous request to finish before starting next Sampler
When the thread doesn't have any more Samplers to execute and loops to iterate - it's being shut down
If you observe the situation when this or that logic was used more than another, most probably the response time for the login was less.
You might want to check the size of the response as for successful requests it should be more or less the same and it might be the situation when the server returns HTTP Status code 200 but response body contains errors, to wit some logins may fail silently, if this is the case it makes sense to add a Response Assertion to add some extra checks, i.e. presence of "Welcome" text or "Logout" link or absence of "error" text or whatever.
What i could understand is you are trying to achieve 8 session each user.in order to do that you have to make 10 concurrent threads and 8 iterations that is how you will achieve 8 session for every credentials.
But of your requirement is to run 80 concurrent users then try to make 80 users and run the test.
Related
I have a work flow designed in JMeter, which I want to execute parallelly. Please refer the image attached. One way to do it that I can use distributed load system and execute the same test plan parallelly. But I have only one machine. Currently I am using parallel controller for executing this and I wonder there must be intelligent way of handling this. Any help on such ?
I don't think your setup is correct, the Parallel Controller executes its children in parallel, it means that
"User 1" will be executed first and all these requests like Retrieve bearer token, retrieve country details, etc. will be executed at exactly the same moment so if retrieve country details requests needs the token - it will fail
"User 2" will be executed after "User1" completion
So I would recommend:
Get rid of the parallel controllers (unless I misunderstood something and all these 5 requests really need to be executed at the same time)
Get rid of these User1, User2, etc and instead parameterize your test using i.e. CSV Data Set Config so each JMeter thread (virtual user) would get its own credentials from the CSV file
Define the required amount of threads (virtual users) and loops (or test duration) on Thread Group level
this way JMeter will start 5 threads (virtual users) in parallel and they will be executing Samplers for 100 iterations or 300 seconds
I need to perform tests on hundreds of HTTP links one after the other.
That means i want to, for instance, perform a 3 minute test with 5 users on 1 link and after that's done, do the same for the next link.
1 way to do this is to create a ThreadGroups for each link, each having a HTTPsampler and just have all of the run consecutively. But i read that that would create memory problems for the testing machine.
So what is the correct way of doing this? I really don't feel like creating and manualy running a separate TestPlan for every link.
You can use only one HTTP Request sampler, the suggested Test Plan structure:
Thread Group with the number of threads (virtual users) you want to simulate
CSV Data Set Config containing the list of URLs
Runtime Controller configured to last 180 seconds
HTTP Request sampler configured to hit the URL:
This way you will hit 1st URL for 180 seconds then 2nd URL for 180 seconds, etc.
For the problem you have mentioned you can create single test plan instead of multiple test plans and add multiple thread groups inside it and make sure that run thread consecutively is checked.
In each thread group mention the thread count and test duration as mentioned in the example below.
We are getting connection timeout for http request after 180 concurrent users are passed? How to handle concurrent users? We are using single login credentials for all 500 users ? Will that effect the flow
We are getting connection timeout for http request after 180 concurrent users are passed? How to handle concurrent users?
What is Thread Group settings Ramp-Up period and do you have Timers in your test?
You can play with different Thread Group types to simulate the actual user behavior as best as possible, because it is a very important. I suppose for now you have all users come in the same moment, so that's why you get connection timeout. So, try to do this:
Setup Ramp-Up period, suitable for you situation.
For instance, if you configure Thread Group to have 100 threads, and set Ramp-up Period to 0 (or to a small number), then all the threads would start at the same time, and it would produce an unwanted spike of the load. On top of that, if you set Ramp-up Period too high, it might result in "too few" threads being available at the very beginning to achieve the required load.
Add Timers to simulate User behavior.
Try another Thread Group types
We are using single login credentials for all 500 users ? Will that effect the flow
Actually, it depends on the application under testing. Better to ask your developer how it deal with multiple user authentication.
But to simulate the actual use of the system is better to use different users. Youu may store and read login and password for them from csv file with CSV Data Set Config
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
My current environment: JMeter v2.11, remote Oracle 12, JDK 7
I have a soak test to generate in Jmeter and I'm unsure quite how to do what I need.
Essentially - I have a recorded script for 200 users to login to a web application within 1 thread group but I need to keep this going for 10 hours.
The http sessions will expire after 15mins, so I'm a little lost how to make the session restart once the http session has expired. I have had a think, I've played with 'Loop Count' settings on the thread group, I've googled for an answer, and I've searched on this forum but I haven't found anything that I can see is relevant (although I did find stuff that was quite interesting).
My current workings are as follows:
Thread Group - Number of Threads --> 200, Ramp Up --> 50, Loop Count ---> 1
--HTTP Request Defaults
--HTTP Cookie Manager
--Recording Controller
---HTTP Request - Login Page Launched
---HTTP Request - Username Input
---HTTP Request - Password Input
---HTTP Request - Login Button selected
---Some listeners
As with my previous posts - I am very grateful for any guidance anyone can provide.
Cheers!
JMeter works as follows:
It starts all defined virtual users (threads) within the bounds of ramp-up period provided. In your case it means that JMeter adds 4 new virtual users each second for 200 seconds.
Each thread executes samplers upside down as fast as it can. when sampler finishes its work and doesn't have more loops to iterate it is being shut down.
If you want your scenario to run over 10 hours set "Loop Count" to "Forever" and specify "Duration" on Thread Group level to be 36000 seconds as per image below:
In this case you'll get 200 concurrent users executing defined samplers for 10 hours.
Another option to specify test (or particular test part) duration is using Runtime Controller
Just in case if you need not 200 concurrent users but 200 requests per second, take a look at Constant Throughput Timer documentation.
Also JMeter acts on protocol level, it doesn't actually type anything into inputs or clicks buttons so my expectation is that you scenario should look as follows:
Open Login Page (HTTP GET)
Perform Login (HTTP POST)
Hope this helps.