I have a thread group that is running non-stop in a VM to simulate user behavior. However I need to stop it after 6 days, since the user token expires (after 6 days) and make the user login again. My thread sequence is as follows-
1. Login (extracts session token and use it in subsequent calls)
2. HTTP req 1
3. Loop controller
a. http req 2
b. http req 3...
Is there a way or script that I can use to auto-stop the thread group after 6 days and auto-restart it again?
The Scheduler on thread group just stops it after a certain time, but I need to auto-restart the thread group again.
If you just need to run JMeter test for 6 days, then restart it you can configure your Thread Group to run for 6 days
and schedule the test execution using your operating system task scheduling mechanisms like crontab for Unix and derivatives or Windows Task Scheduler. One more option is putting your JMeter test under orchestration of a Continuous Integration server like Jenkins
If for some reason the above options are not suitable, i.e. you don't have permissions to install 3rd-party software or add a scheduled tasks on OS level what's the problem in putting the Login (extracts session token and use it in subsequent calls) into a separate Thread Group and use Constant Timer or Flow Control Action Sampler in order to make this Login to fire once per 6 days? The token and stuff can be passed to the "main" Thread Group via __setProperty() function or Inter-Thread Communication Plugin
You could modify your original Test Plan structure in one of the following ways:
1. Login
2. HTTP req 1
3. While Controller
a. http req 2
b. http req 3...
The While Controller could run for 6 days after which the outer Thread Group would loop around for another login.
The While condition would have to compare the time difference between the current time and TESTSTART.MS (see https://jmeter.apache.org/usermanual/functions.html#predefinedprops) and take into account the number of previous logins i.e. number of Thread Group iterations (e.g. __jm__Thread Group__idx).
1. If Controller
a. Login
b. HTTP req 1
2. http req 2
3. http req 3...
Alternatively, an If Controller could run only once every 6 days with a condition similar to the above.
Related
I am running one scenario for 2 hours in which I am using service which generates the cookie.. and that cookie is getting expired after 30 minutes.
So I want to create a thread group which will run after 30 minutes so that new cookie will get replace with old cookies.
You can setup another thread group with a 30min startup delay.
Add a constant timer with 30min to ensure the delay after the first execution.
Best approach could be to check the expiry with a If Controller and add the requests within the if controller.
To make this simple
Create a thread group with number of threads as 1 with ramp up as 1 second.
Create a loop controller and add loop count as 4.
Create your request under this loop controller and also add constant timer as child of your request as shown below :
Execution flow will be:
First request will get executed . Once this first request gets a response from the server, it will wait for 30 mins. Then this loops again 4 times. You can control the number of execution in the loop count.
The options are in:
Just specify "Startup delay" for the Thread Group:
Add Flow Control Action sampler as the first sampler in the Thread Group and configure it to pause for the half and hour:
Use custom thread group like Ultimate Thread Group (can be installed as a part of Custom Thread Groups bundle using JMeter Plugins Manager) where you can precisely define when and how to start threads:
I need write the following scenario in JMeter
Login via http request and in parallel sending calls for 8 hours.
After that running in parallel Login and Logoff and sending calls again for 8 hours
After that running in parallel Login and Logoff and sending calls again for 8 hours
After that running in parallel Login and Logoff and sending calls again for 8 hours
and after N runs … start everything from beginning.
I created N thread groups , and added parallel controller , and under the parallel controller i added the loop controller of Login , Logout, sending calls
it didn't worked , the test stops after running the first run of thread group, it doesn't run as duration time .
what i m doing wrong , maybe i have to write the test plan different?
We cannot say anything meaningful without seeing your Thread Group configuration, for now I can only state that your test will end when:
the last user finishes the last iteration specified in the Loop Count
the test duration exceeds the "Duration"
whatever comes the first.
So make sure to tick "Infinite" box and specify the desired duration of your test plan
Also be aware that according to the How to Use the Parallel Controller in JMeter the Parallel Controller runs its children in parallel. Once. The main use case for the parallel controller is simulating AJAX requests to bypass JMeter's limitation of "one virtual user = one thread", maybe for your test scenario it makes sense to increase the number of threads in the Thread Group instead of going for Parallel Controller.
And last but not the least, be aware of the Runtime Controller which executes its children for the specified duration.
I have scenario where I want to run load test for 250 users.
Ramp up time is 10 mins for 250 users and run test for 50 min duration.
Question 1 : Is it recommended to do login and login out as part of set and tear down .. as the dev team does not measure login and log out .?
Question 2 : How do i keep the the other thread group in loops during the 50 min duration . ?
I wouldn't go for it as normally different thread groups should represent the different groups of virtual users, setUp thread group is for accomplishing the pre-conditions for the test and tearDown thread group is for cleaning everything up. If you perform the login in the setup thread group - there will be negative consequences like having to pass login context (tokens, headers, cache, etc.) to other thread groups. So I would rather move login to be the integral part of the main thread group and if needed remove login/logout via Filter Results Tool (not part of vanilla JMeter, can be installed using JMeter Plugins Manager)
It can be done on either on Thread Group level like this:
or you can "loop" the arbitrary part of the test by putting it under the Runtime Controller:
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.
I have to simulate multiple user logging in and going through a sequence of web services in JMeter. The web services are-
1.login
2.startjob
3.endjob
4.logout
I have 10 users and all of them will simultaneously login and run through the steps 1-4.
The steps are-
User will login using "login" service. They will get a session token (ST) in the response.
Using the ST from above step the user will start the job using "startjob" service
After the job is finished, "endjob" service is used.
Finally user is logged out using "logout" service.
So far I have been able to do the above steps properly for one user.
I have created a CSV file with 10 usernames and passwords and am able to make only the "login" service iterate through all users using CSV Data Set Config.
How do I make each individual user go through steps 1-4?
In JMeter, each individual Thread or User will execute every sample within it in upside-down order. So for a single user, when we run the test, the result will appear in that order. But Ramp up time is related to Thread creation:
How long JMeter should take to get all the threads started is the
Ramp up time.
Within this time, all the users will be initiated and all those Threads will execute the samples underlying it in the same fashion as it does for a single user.So in you case, all the 10 thread will go through steps 1-4, but the threads will initiate within your ramp up time.
If you observe the output in View Results in Table listener and trace the Start Time of the samples for a corresponding Thread, you will see that those samples are executed through the steps of 1-4.
For an example, I have 4 samples under my Thread Group and I have defined Threads or Users : 3 and Ramp up : 5. All those three Threads executed the samples Through 1 to 4.
Image here: