I have 1 thread Group, Within that I have 5 HTTP Request calls. 1st HTTP Request returns a value & that value is used in rest 4 HTTP Requests. The Thread Group Set Up with Number of Thread (Users) : 7 & Ramp-Up period : 5 & Loop Count : infinite. When I run the thread group it breaks due to concurrency.
Example:
When User Thread 1 executes -> Request 1,
Thread 2 executes -> Request 2 (It expects a value from Request 1, Which has not happened for thread 2, Hence it breaks).
Please find the Jmeter SetUp Images below,
Thread
HttpCookieManager
I am new to Jmeter please help me in this.
Each JMeter thread (virtual user) executes Samplers upside down (or according to the Logic Controllers
JMeter Variables are local for the thread (virtual user)
So there is no option that Thread 1 executes Sampler 1 and Thread 2 executes Sampler 2, all users will be executing all Samplers sequentially, it can be checked using __threadNum() function:
So my expectation is that either your extractor fails or Sampler 1 execution by Thread 2 fails somewhere somehow, check the requests and responses using View Results Tree listener, the JMeter Variables using Debug Sampler and jmeter.log file for any suspicious entries.
Related
I'm trying to write a script with two users, 5 second constant time sampler between each request and 3 iterations.
For Users, Thread Group - No of users 2
For iterations, Thread Group - Loop Count 3
For Timer, Thread Group - Constant Timer 5000ms
My Hierarchy is as follows: Test plan
Thread Group
Constant Timer
Logic Controller
Action 1
Action 2
Listener View Result table
Is this approach correct, I'm unable to validate if the sampler request time is 5 seconds from the output.
You can add some extra information to your Sampler label, for example:
${__threadNum} function which returns the number of current virtual user
${__jm__Thread Group__idx} pre-defined variable which returns current Thread Group iteration
So if you modify your samplers labels to look like:
User: ${__threadNum}, Iteration: ${__jm__Thread Group__idx}, Sampler 1
User: ${__threadNum}, Iteration: ${__jm__Thread Group__idx}, Sampler 2
You will be able to see the 5 second intervals between Sampler 1 and Sampler 2 and between iterations.
I have 1 thread group with 4 HTTP requests, each using separate csv to get input(json).
I want to run load testing with 100 users for 10 loops for all of them.
Expected result: run HTTP request 1 for 100*10 times then move to HTTP request 2 and run 100*10 times and so on.
First HTTP request is provided with correct values and second with incorrect values, So first HTTP request gives 0% error and 2nd thread gives 100% error.
Issue: While running thread, 2nd HTTP request is also giving 0% error instead of 100% as it is somehow picking values from same csv as the first HTTP request(they both have separate CSV data set config with separate csv files having different data), while they are working fine individually.
My test plan
CSV Data Set configuration
In the same Thread Group all threads will be running simultaneously, there's no configuration option that would allow HTTP requests in the same thread group to run sequentially. So you can fix it in one of the following ways:
Put each HTTP request in its own Thread Group, and use Run Thread Groups Consecutively option
Thread Group 1
HTTP Request 1
Thread Group 2
HTTP Request 2
...
Use controllers and timers to get each HTTP request executed in loop and all threads to wait before starting the next one:
Thread Group
Loop Controller <-- set Loop Count to 10
HTTP Request 1
Synchronizing Timer <-- set Group by parameter to 100, so you wait for all threads to finish with first loop
Loop Controller
HTTP Request 2
Synchronizing Timer
...
In JMeter, I have a requirement where I want to run a particular thread group after all the other thread groups complete their run, I know the tearDown thread group has the similar behavior but unfortunately, the logic has to be part of my regular thread.
Let's say there are 4 thread groups A,B,C & D in my test plan and I want the thread group D only to be executed after A, B & C will complete their run.
Can we achieve this without using "setup, teardown & Run groups one at a time" ??
Problem ScreenShot:
I can suggest 2 options:
Use Inter-Thread Communication Plugin. See example test plan for details.
If for some reason you are not in position to use JMeter Plugins you can achieve the same using JMeter Properties like:
When Thread Group A finishes set a JMeter Property, i.e. ThreadGroupADone=true using __setProperty() function like
${__setProperty(ThreadGroupADone,true,)}
In Thread Group D:
Add While Controller at the beginning of the Thread Group and use the following condition:
${__javaScript("${__P(ThreadGroupADone,)}"=="false",)}
Add Test Action sampler as a child of the While Controller and configure it to pause for a reasonable amount of seconds, i.e. 5 so each 5 seconds While Controller will check ThreadGroupADone property value and if it is still false - sleep for another 5 seconds. When property value will become true - Thread Group D will proceed.
This may sound like a duplicate question but its nit, I've searched a lot before putting this here.
I have a single thread group with 10 users and 28 HTTP requests, what I want is something like:
Thread 1 --->rqst 1
Thread 1 --->rqst 2
Thread 1 --->rqst 3
.
.
Thread 2 --->rqst 1
Thread 2 --->rqst 2
Thread 2 --->rqst 3
.
.
Thread n --->rqst n
delay one minute
Start over again.
I tried using constant timer in the thread group but what i got was execution of a single request by all threads every time.
Can anyone please explain how this can be achieved.
There are at least 2 options:
Add Test Action Sampler after all requests and configure it like:
Target: All Threads
Action: Pause
Duration: 60000
Add Constant Timer as a child of rqst 1. Timers are executed before sampler so only one request will be impacted. See A Comprehensive Guide to Using JMeter Timers for more details on timers scope and detailed explanation of each and every Timer.
In both cases delay won't be included into test results
Add a beanshell timer after the last request with something like this
if (${__threadNum} == 10){
Integer WaitTime = Integer.parseInt(vars.get("WaitTime"));
return WaitTime;
}
If the last thread has started add a sleep with milliseconds from the var WaitTime.
Or take a loop at the jp#gc - Stepping Thread Group plugin.
I have 3 Thread Groups: Setup Thread Group, Thread Group 2(which has the http request which does the download of the file), Thread Group 3 under a single Test Plan. The thread count=3 for each. The checkbox 'Run consecutively' is deselected in the Test plan.
The Setup thread group has all the pre-requisite requests which are needed to be executed prior to Thread Group 2 and 3. The Setup Thread Group(having multiple https requests) writes some authentication tokens to 2 different csv files which will then be utilized by the other 2 thread groups respectively when they get executed in parallel at later point of time. So, csv file1 will be used by Thread Group 2 and csv file2 will be used by Thread Group 3.
First, the Setup Thread Group gets executed.Then the Thread Group 2 and Thread Group 3 get executed in parallel. Everything seems fine when all of the threads of Setup Thread Group get the successful response:200.
But when there is any erroneous response like 500 in one of the Setup Thread Group thread Response, the csv files get less number of entries(which is fine); and the Thread Group 2 and Thread Group 3 do not run in parallel. The Thread group 3 runs first. Then after some time gap, the Thread group 2 runs. What's the cause and resolution for this problem?
1) Set Up Thread: Extract the response code or any response message of the Last sampler of the Set Up Thread.
2) Before proceeding Thread group 2 or 3 add some constant time and a BSF pre-processor. validate the condition of the extracted value(either response code/response message).
If the anticipated value is found, proceed with Thread group 2 and 3.
If not Add some constant time within the BSF(define a condition).
3) do the simlar approach, to wait for Thread Group-3 to ensure Thread Group-2 has ran succesfully.