I have 100 thread groups under a single test plan.And I want to run my load test for particular date and time for example 2018/03/20 12:55:15 to 2018/03/20 13:55:15 for all of my thread groups.So it is not feasible to manually copy paste same date in all thread group which is time consuming.
So is there any way so that I can automate start time and end time in the scheduler configurations such that in a single process i can run all the thread groups for a particular time interval???
You can easily achieve it with the help of Taurus tool, it naturally supports JMeter .jmx scripts and you can amend properties in them (including Thread Groups start time) using simple YAML syntax.
Example configuration will look like:
---
execution:
scenario:
script: test.jmx
modifications:
set-prop:
"Thread Group>ThreadGroup.start_time" : 1521985369558
Change 1521985369558 to the desired Thread Group start time (in form of milliseconds since start of Unix epoch)
References:
Modifications for Existing Scripts
Navigating your First Steps Using Taurus
Related
Is it possible to run a portion of the script via command line in JMeter?
Here is what I am trying to do. I have multi-thread groups in a script. Let's say one is Stepping Thread Group and another one is tear down thread group for the same samplers, CSV files etc. Everything is the same. Now I want to run sometimes only thread group and sometimes only Stepping Thread Group.
I know we can do it from the GUI by disabling the thread group, but I want to do it from the command line to avoid manual steps. Is it possible?
Just define number of threads for both Thread Groups using __P() function, like:
For Stepping Thread Group:
${__P(stepping.threads,1)}
For tearDown Thread Group
${__P(teardown.threads,1)}
Whenever you want to disable certain Thread Group from command-line non-GUI mode - just set the number of threads for the specific thread group to 0 via -J command-line argument
i.e.
jmeter -Jstepping.threads=50 -Jteardown.threads=0 -n -t ... - will run the Stepping Thread Group with 50 virtual users and will not run the tearDown Thread Group
and
jmeter -Jstepping.threads=0 -Jteardown.threads=1 - will not run the Stepping Thread Group and will run the tearDown Thread Group with 1 virtual user
Alternative solution would be running your JMeter test using Taurus tool as the wrapper. Taurus provides Modifications for Existing Scripts functionality so you will be able to enable/disable arbitrary Test Elements using simple declarative YAML syntax like:
---
execution:
scenario:
script: test.jmx
modifications:
disable: # Names of the tree elements to disable
- jp#gc - Stepping Thread Group (deprecated)
enable: # Names of the tree elements to enable
- tearDown Thread Group
See Navigating your First Steps Using Taurus article for more information.
The test scripts on GUI works perfect but not in the non-GUI mode.Image showing Terminal test execution
Explanation:
I have 3 thread groups in the test plan, where the first Thread Group creates 3 .csv files and are expected to feed the data in the CSV files into the second Thread Group.
For few test runs, Non-GUI mode worked great but then, the tests Intermittently like this [Terminal showing test run], doesn't create the CSV files at all and also,
sometimes, third Thread Group doesn't execute at all.
The problem I noticed is:
During the NOn-GUI tests the files are not been creating, so that's the reason the next Thread groups weren't able to pick up and use the variables inside CSV file and also
The second One could be: I'm saving folder and file paths in the
${__setProperty(prop_folder_Path,${File_Path})} and getting the prop.
${__property(prop_folder_Path)} in another Thread Group -> Sometimes this property function Doesn't work and files are saving in /bin Directory
Is there a way to use ${__property(prop_folder_Path)} value in BeanShell POStProcessor ?
I believe whatever works in the GUI should work same in the Non-GUI too, AM I right?
I Just noticed that output files are creating in /bin folderas shown here while running the tests in NOn-GUI
Any suggestions to fix this. Thank you
My expectation is that your ".csv" files creation fails somewhere somehow therefore 2nd thread group is not able to operate due to missing files.
JMeter doesn't have any build-in functionality to write something into the file so I think you implemented some custom logic using i.e. JSR223 Scripting which doesn't work. The reasons could be in:
If you're running JMeter from another folder the .csv files can be created in a different location, try using full paths just in case.
Non-GUI mode tends to be faster than GUI mode so it might be the case of multithreading issue i.e. when multiple threads are trying to write data into the same file concurrently and clash or produce not well-formed data.
In both cases the answer will live in jmeter.log file, check it for any suspicious entries and fix the causes.
In general using files to pass data between thread groups is not the best idea, I would recommend doing it in-memory instead, for example:
In 1st Thread Group use __setProperty() function to convert your data which you store in CSV file into JMeter Properties like:
${__setProperty(foo,bar,)}
In 2nd Thread Group use __P() function to read the data like:
${__P(foo,)}
More information: Knit One Pearl Two: How to Use Variables in Different Thread Groups
I want to run any specific Thread Group with Command in windows. I have tried with using properties file but got failed. Now need help for executing any specific thread group selecting from command prompt.
You can easily achieve this using Taurus tool. It is a wrapper around JMeter (and several other performance testing tools) which provides an easy way of configure (or create) and run a JMeter test using simple YAML syntax.
For instance if you need to disable Thread Group B the relevant configuration would be something like:
---
execution:
scenario:
script: test.jmx
modifications:
disable: # Names of the tree elements to disable
- Thread Group B
enable: # Names of the tree elements to enable
- Thread Group A
References:
Modifications for Existing Scripts
Navigating your First Steps Using Taurus
If Thread group's Number of Threads is set to 0 it won't execute.
Based on that, you can set for each thread group Number of Threads with __property with default 0 per group number, e.g. for Thread group 1:
${__property(group1,,0)}
so if you execute in command prompt jmeter -Jgroup3=1 ... - if you want only thread group 3 be executed with 1 thread/user (other groups will have 0 users and won't get executed)
I want to run a thread x times. The thread group contains three samplers and because I dont want them to be mixed up in the result windows I only want to start the next thread when another is finished. I don't want to use a Ramp-Up Period because a thread could take 1 to 20 seconds.
You could use 3 thread groups and module controller (to referencd in the 2 other thread groups the elements in the first one to avoid copy ) and check on test plan the option:
Run Thread Group sequentially
Your use case is not very clear, however if you need to limit JMeter to X concurrent threads only the most obvious choice would be going for the Concurrency Thread Group
As per Advanced Load Testing Scenarios with JMeter Part 4 - Stepping Thread Group and Concurrency Thread Group article:
The Concurrency Thread Group provides a better simulation of user behaviour because it lets you control the length of your test more easily, and it creates replacement threads in case a thread finishes in the middle of the process.
You can install Concurrency Thread Group as a part of Custom Threads Group bundle using JMeter Plugins Manager
Regarding your three listeners bit, I would recommend reconsidering this approach as per JMeter Best Practices you should not be using any listeners, instead of it you need to run JMeter in non-GUI mode and use -l command-line argument to specify the results file name. Once your test is finished you can open the .jtl results file with a listener of your choice or generate a reporting dashboard from it.
You can use "jp#gc - Ultimate Thread Group". The Ultimate Thread Group provides flexible thread scheduling to your test scenario. It allows us to create a scheduled thread with advanced configuration. Start Threads Count, Initial Delay, Startup Time and Hold Load Time can be defined separately for each record.
You can define tasks to run consecutively.
This platform support flexible thread scheduling. You can read detailed wiki docs about the ultimate thread group.
Link: Loadium.com/wiki/ultimate thread
First script
Thread-1
|--Http Sampler
|--Include Controller <second script>
Second script
TestPlan
|--Thread-2
| |--Http Sampler
|--Thread-3
|--Http Sampler
I run the first script which does few steps and uses include controller to call the next script. I need the second script Thread groups (Thread-2 and Thread-3) run simultaneously and not consecutively.
I understand the thread run concurrently by default. But when I execute my code i see:
Thread-1 successful
Thread-2 successful
Execution never gets to thread-3
Can you please help me? I want to know how to run the second script's thread group simultaneously?
You are misusing IncludeController, you need to use Test Fragment element in the included test plan (second script)
First and second script are separate test plans.
First Test Plan contains one thread, which contains a include controller to call the second script or the second Test plan
Second test plan contains 2 thread groups
Solution:
In both the Test Plan untick "Run threads consecutively"
In the second test plan tick "Delayed thread creation" - this means that the memory requirements are proportional to the number of concurrent active threads, rather than the total thread count
Threads in JMeter run simultaneously by default.
Understand the difference between concurrency and simultaneous. Here is a helpful link: How to generate Concurrent User load in Jmeter