Jmeter delay between threads - for-loop

I am using JMeter for performance testing. I am using csv file and there are 8 lines of data. I want to execute 3 threads in parallel at a time.
1,2,3 - execute in parallel
1 minute time delay
then 4,5,6 - parallel
1 minute time delay
then
7,8 - parallel execution
I am using JSR223 timer. I used the below code:
if(ctx.getThreadNum()%3==0) {
sleep(60000);
}
Here its sleeping at thread 3 and 6 but not as I mentioned above. Could someone please provide a idea on this?

Maybe it would be easier to switch to Parallel Controller like:
Parallel Controller
1
2
3
Flow Control Action for delay
Parallel Controller
4
5
6
Flow Control Action for delay
Parallel Controller
7
8
The similar behaviour can be achieved using Synchronizing Timer if you cannot or unwilling to use the Parallel Controller

Related

Jmeter request and report validation

My Requirement is to execute 10 request per second for 5 minutes. The configuration I have used is
Thread Group Properties:
number of threads : 600
ramp up period : 60
Loop count : 5,
Add Sampler -> Flow Control Action
Select Logical Action on thread as Pause
Duration(milliseconds) :60000
I used the below command to run jmx from command line to generate xls and generate html report.
/jmeter.sh -n -t demo.jmx -l demo.xls -e -o ./report
Need to know if the configuration I have mapped is correct or not?
I have also looked at constant throughput timer and Runtime controller to stop the execution after 5 mins?
I am not able to validate the end result?
You can see what actual throughput your test generated using Transactions Per Second listener or the relevant chart in the HTML Reporting Dashboard
With regards to configuring JMeter for sending 10 requests per second for 5 minutes I would rather recommend going for Concurrency Thread Group and Throughput Shaping Timer combination.
Configurations:

Is it possible to run threads at different time interval- JMeter

I have 8 threads in JMeter, which i am executing for every 5 minutes using Task scheduler.
Now i have included 2 threads which want to run for 5 times per day only (ex: at 12am, 5am,10am...)
when the moment comes, the execution shall be 8+2 & remaining time, it shall be only 8 threads.
Is it possible to configure such usecase in Jmeter..
If you're going to use the same .jmx script and want to execute either 8 or 10 "threads" (whatever it is), you can go for:
If Controller - for conditional execution of this or that test elements
__groovy() function to check current time, an example condition which trigger the test at i.e. 5 AM would be:
${__groovy(Calendar.getInstance().get(Calendar.HOUR_OF_DAY) == 5 && Calendar.getInstance().get(Calendar.MINUTE) == 0,)}

Runtime Controller in Jmeter

Can you help me to explain relationship between time in Runtime Controller and Ramp_up period value of Thread group?
I tested
Number of Thread: 1
Ramp_Up Period: 1
Loop count: 1
Runtime Controller: 5s
->Elapsed time of current running test: 5s
But with case
Number of Thread: 5
Ramp_Up Period: 5
Loop count: 1
Runtime Controller: 5s
->Elapsed time of current running test: 10s
I don't understand why it become 10s.
Could you help me to explain more?
Ramp up is the time to execute all threads, runtime is controlling each thread execution.
In your case, ramp up 5 seconds means last thread will be executed after 5 seconds. Last thread will enter runtime controller which will run 5 seconds of execution. Thus 10 seconds is the maximum of your execution.
Runtime Controller acts according to JMeter Scoping Rules so it defines how long its children are allowed to run.
Normally you should be using it in conjunction with Loop Count = Forever or -1 on either Thread Group or Loop Controller level.
So
if you want the whole test to run for 5 seconds - use "Scheduler" section of the Thread Group
if you want only certain sampler(s) to run for 5 seconds - put them under the Runtime Controller, however the whole test duration will depend on when the last sampler enters the Runtime Controller
Also be aware that JMeter "asks" threads to stop so it might take some extra time to let them gracefully shut down.

Adding a delay in a thread group - JMeter

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.

JMeter - How to implement "N users fire up N different queries simultaneously" scenario

I have trouble implementing the following scenario and Google did't help - may be I am missing something obvious?
Scenario is :
Step 1. 9 sesssions simultaneously running 3 different JDBC queries, i.e
3*Q1,3*Q2,3*Q3 all starting and running at the same time
Clarification: In the beginning of step 1, the following queries will start in 9 different sessions - Q1,Q1,Q1,Q2,Q2,Q2,Q3,Q3,Q3
Step 2. 27 sessions like
above (9 times each query)
Step 3. 54 sessions (18 times each query)
Steps must run sequentially.
To do so:
Step 1)
3 thread groups, each one with 3 threads, each thread group calling a different Qi
Step2)
3 thread groups, each one with 9 threads, each thread group calling a different Qi with scheduler delayed so that it starts after step1 has finished
Step3)
Same as step2 with 18 threads and delayed so that it starts after step 2
But I must say I don't understand why you need such behaviour

Resources