This repository is used to build and maintain OpenText Enterprise Performance Engineering GitHub Action.
ExecuteLreTest action - Execute load tests on OpenText Enterprise Performance Engineering server. At runtime, the action:
- Authenticates with an OpenText Enterprise Performance Engineering server
- Triggers a performance test execution
- Allocates or reuses a timeslot (based on configuration)
- Monitors test execution until completion
- Optionally collates and analyzes results
- Writes logs and result artifacts to configured directories
- Exits with a deterministic status code suitable for pipeline gating
WorkspaceSync action (Technology Preview) - Synchronize local workspace scripts to OpenText Enterprise Performance Engineering server. At runtime, the action:
- Authenticates with an OpenText Enterprise Performance Engineering server
- Scans the workspace for folders considered as supported scripts. Folders identified as scripts are:
- VuGen scripts: folders containing a .usr file
- JMeter scripts: folders containing a .jmx file
- Gatling scripts: folders containing a .scala file
- Selenium or unit test scripts: folders containing a .java file
- DevWeb scripts: folders containing both main.js AND rts.yml files
- Zips each folder identified as script and uploads it to OpenText Enterprise Performance Engineering project
- Failure handling:
- If 5 consecutive script uploads fail, the action is interrupted with failure
- A configurable success threshold (
lre_workspace_sync_success_threshold) decides pass/fail based on upload success percentage - Otherwise, the action reports failure
- Writes logs for each upload in console and in workspace
- Exits with a deterministic status code suitable for pipeline gating
- Any workflow including this action will need to have preliminary steps such as (see example below):
- actions/checkout@v6 to checkout git repository into GitHub job workspace.
- actions/setup-java@v5 (version 17) to setup environment with java 17.
- actions/setup-node@v6 (version 25 for example or latest) to setup environment with nodejs .
- Usernames and passwords will need to be saved as secrets and used as environment variables in the workflow.
- If you want to save reports as build artifacts, you can add the following step: actions/upload-artifact@v7 (see example below).
- Writable workspace and output directories.
- Network access to the OpenText Enterprise Performance Engineering server
- Valid OpenText Enterprise Performance Engineering credentials (username/password or token).
This action only needs read access to repository contents.
Minimum recommended permissions in your workflow:
permissions:
contents: read # required for actions/checkout and git-diff detection
actions: read # required for WorkspaceSync incremental sync since last successful buildNotes:
contents: readis required foractions/checkoutand forgit diffused during incrementalWorkspaceSync.actions: readis required forWorkspaceSyncto query the GitHub Actions API and determine the last successful run's commit SHA.- Both permissions are required for incremental sync. If either is missing,
WorkspaceSyncperforms a full sync of all scripts. - No repository write permission is required for the current action behavior (including incremental sync and optional deleted-script handling in LRE).
- If your organization enforces restricted default token permissions, explicitly set the
permissionsblock as shown above.
The action supports two operation modes:
ExecuteLreTest: trigger and monitor a performance test run.WorkspaceSync: scan a local workspace and upload detected scripts to OpenText Enterprise Performance Engineering.
| Input | Description | Action |
|---|---|---|
| lre_server | Server, port (when not mentioned, default is 80 or 443 for secure), and tenant (when not mentioned, default is ?tenant=fa128c06-5436-413d-9cfa-9f04bb738df3). Example: mylreserver.mydomain.com:81/?tenant=fa128c06-5436-413d-9cfa-9f04bb738df3 |
Both |
| lre_username | Username (or ID part of token) | Both |
| lre_password | Password (or secret part of token) | Both |
| lre_domain | Domain (case sensitive) | Both |
| lre_project | Project (case sensitive) | Both |
| lre_test | Required when lre_action=ExecuteLreTest. Valid test ID# or relative path to a YAML file in the workspace that defines new test design creation |
ExecuteLreTest |
* Either username/password or token authentication must be used.
| Input | Description | Action | Default |
|---|---|---|---|
| lre_action | Action to be triggered. Supported values: ExecuteLreTest, WorkspaceSync. If not defined, ExecuteLreTest is used. | Both | ExecuteLreTest |
| lre_description | Description of the action (displayed in logs) | Both | |
| lre_https_protocol | Use secured protocol for connecting to the server (true / false) |
Both | true |
| lre_authenticate_with_token | Use token authentication (required for SSO). (true / false) |
Both | false |
| lre_workspace_dir | Local workspace root path. For WorkspaceSync this is the directory scanned for scripts and where logs are written to <workspace>/logs |
Both | If omitted, resolved with lre_output_dir; if both are omitted, ./ |
| lre_test_instance | AUTO or specific instance ID |
ExecuteLreTest | AUTO |
| lre_timeslot_duration_hours | Timeslot duration (hours) | ExecuteLreTest | 0 |
| lre_timeslot_duration_minutes | Timeslot duration (minutes) | ExecuteLreTest | 30 |
| lre_post_run_action | Collate Results, Collate and Analyze, Do Not Collate |
ExecuteLreTest | Do Not Collate |
| lre_vuds_mode | Use VUDS licenses (true / false) |
ExecuteLreTest | false |
| lre_trend_report | ASSOCIATED - the trend report defined in the test design will be used', Valid report ID - Report ID will be used for trend, No value or not defined - no trend monitoring. |
ExecuteLreTest | |
| lre_proxy_out_url | Proxy URL | Both | |
| lre_username_proxy | Proxy username | Both | |
| lre_password_proxy | Proxy password | Both | |
| lre_search_timeslot | Experimental: Search for matching timeslot instead of creating a new timeslot (true / false) |
ExecuteLreTest | false |
| lre_status_by_sla | Report success based on SLA (true / false) |
ExecuteLreTest | false |
| lre_output_dir | Directory to read the checkout folder and to save results (use ${{ github.workspace }}) |
ExecuteLreTest | ./ |
| lre_runtime_only | Scripts upload mode (Runtime files only for true, All files for false) (true / false) |
WorkspaceSync | true |
| lre_workspace_sync_success_threshold | WorkspaceSync success threshold in percent (0-100). 0 never fails on upload ratio, 100 requires all uploads to succeed. Out-of-range values fall back to 50 |
WorkspaceSync | 50 |
| lre_workspace_sync_base_sha | WorkspaceSync only. Optional explicit base commit SHA used to compute changed files for incremental sync | WorkspaceSync | |
| lre_workspace_sync_delete_removed_scripts | WorkspaceSync only. If true, incremental sync also deletes scripts in LRE when their script folders were removed from the repository. If false (default), deleted scripts are ignored |
WorkspaceSync | false |
| lre_enable_stacktrace | Print stacktrace on errors (true / false) |
Both | false |
When lre_action is set to WorkspaceSync, the action scans lre_workspace_dir recursively and uploads script folders found in the workspace hierarchy. A folder is treated as a script folder when it contains one of the supported script formats (for example .usr, .jmx, .java) or DevWeb script markers (main.js and rts.yml).
Each detected script folder is zipped and uploaded to the matching subject path in OpenText Enterprise Performance Engineering, preserving the relative folder structure under Subject.
The sync result is considered successful when the successful upload percentage is greater than or equal to lre_workspace_sync_success_threshold (default 50). A value of 0 always passes the ratio check, and 100 requires all uploads to succeed. Out-of-range values fall back to 50. The process also stops early after 5 consecutive upload failures.
Incremental Sync Behavior: The action automatically detects and uses incremental sync when possible. On push events, it queries the GitHub Actions REST API (using GITHUB_TOKEN, requires actions: read permission) to find the last successful run's commit SHA and uses it as the base for the diff. This ensures that if a previous build failed, all changes since the last successful sync are included in the next run — nothing is silently skipped.
Both actions: read permission and fetch-depth: 0 on the checkout step are required for incremental sync. If either condition is not met, the action performs a full sync of all scripts — there is no partial fallback.
For pull request events, the PR base branch commit is used as the diff base, and only fetch-depth: 0 is required. If no usable commit context can be determined, the action falls back to full sync.
Fallback summary:
actions: read |
fetch-depth: 0 |
Result |
|---|---|---|
| ✅ | ✅ | Incremental since last successful build |
| ❌ | ✅ | Full sync |
| ✅ | ❌ | Full sync (git diff fails on shallow clone) |
| ❌ | ❌ | Full sync |
When lre_workspace_sync_delete_removed_scripts is enabled, the action attempts to delete matching scripts from the LRE project for script folders removed from the repository in the detected git diff range. By default (false), script deletions are ignored.
Important Note on File Deletions: When files are deleted from within a script folder (e.g., a file within a .jmx or .usr folder is removed), this represents an update to that script, not a script deletion. The script folder itself still exists and is still recognized as a script. Script deletion only occurs when the entire script folder is removed from the repository, or when the folder no longer contains the markers that identify it as a script (e.g., the .jmx file is deleted from a JMeter script folder). In such cases, lre_workspace_sync_delete_removed_scripts will delete the corresponding script from the LRE project.
Directory resolution note: if lre_output_dir and lre_workspace_dir are both omitted, both resolve to ./.
| Path | Purpose |
|---|---|
| lre_output_dir | Result files and summarized outputs |
| lre_workspace_dir | Workspace for logs, reports, and checkout |
These directories must be writable.
| Version | Date | Highlights |
|---|---|---|
| 1.0.7 | 2026-05-17 | - Added optional handling of deleted scripts during incremental WorkspaceSync via lre_workspace_sync_delete_removed_scripts- Incremental sync can now upload changed scripts and optionally delete removed scripts in one run |
| 1.0.6 | 2026-05-17 | - Updated the GitHub Action runtime to node24 to stay compatible with the current GitHub Actions runner deprecation schedule |
| 1.0.5 | 2026-05-17 | - Added lre_workspace_sync_success_threshold for WorkspaceSync (0-100, fallback to 50)- WorkspaceSync now passes/fails based on the configured upload success percentage- Improved lre_run_id availability for ExecuteLreTest outputs in workflow steps |
| 1.0.4 | Previous release | - Baseline behavior before the new WorkspaceSync threshold and lre_run_id output reliability improvements |
Authenticate using a :token (access key), create a performance test from YamlTest/createTestFromYaml.yaml in the GitHub repository, execute it, wait for analysis and trending to complete, download reports, and upload them as build artifacts
name: Create performance test according to YamlTest/createTestFromYaml.yaml and execute it
on:
push:
branches:
- main
jobs:
test:
runs-on: ubuntu-latest
name: Start a performance test
permissions:
contents: read
env:
lre_username: ${{ secrets.LRE_USERNAME }}
lre_password: ${{ secrets.LRE_PASSWORD }}
steps:
- name: Checkout code
uses: actions/checkout@v6
- name: Setup Java
uses: actions/setup-java@v5
with:
distribution: adopt
java-version: '17'
- name: Set up Node.js
uses: actions/setup-node@v6
with:
node-version: '25'
- name: Use GitHub Action
uses: MicroFocus/lre-gh-action@v1.0.7
with:
lre_action: ExecuteLreTest
lre_description: running new yaml test
lre_server: mylreserver.mydomain.com/?tenant=fa128c06-5436-413d-9cfa-9f04bb738df3
lre_https_protocol: true
lre_authenticate_with_token: true
lre_domain: DANIEL
lre_project: proj1
lre_test: YamlTest/createTestFromYaml.yaml
lre_test_instance: AUTO
lre_timeslot_duration_hours: 0
lre_timeslot_duration_minutes: 30
lre_post_run_action: Collate and Analyze
lre_vuds_mode: false
lre_trend_report: ASSOCIATED
lre_status_by_sla: false
lre_output_dir: ${{ github.workspace }}
- name: Upload build artifacts
uses: actions/upload-artifact@v7
with:
name: build-artifacts
path: ${{ github.workspace }}/LreResultContent of YamlTest/createTestFromYaml.yaml from the example (when using script_path, the script with the mentioned path must exist under the Subject root of Test Plan. Otherwise, you can use script_id to refer to the script by its ID):
##################################################
group:
- group_name: "demo_script_new"
vusers: '2'
#script_id: 175
script_path: "daniel\\scripts\\demo_script_new"
lg_name:
- "LG1"
scheduler:
rampup: '10'
duration: '60'
automatic_trending:
report_id: 6
max_runs_in_report: 3
##################################################Authenticate using username and password (lre_authenticate_with_token: false), execute a performance test, wait for analysis and trending to complete, download reports, and upload them as build artifacts.
name: test
on:
push:
branches:
- main
jobs:
test:
runs-on: ubuntu-latest
name: Execute test
permissions:
contents: read
env:
lre_username: ${{ secrets.LRE_USERNAME }}
lre_password: ${{ secrets.LRE_PASSWORD }}
steps:
- name: Checkout code
uses: actions/checkout@v6
- name: Setup Java
uses: actions/setup-java@v5
with:
distribution: adopt
java-version: '17'
- name: Set up Node.js
uses: actions/setup-node@v6
with:
node-version: '25'
- name: Use My GitHub Action
uses: MicroFocus/lre-gh-action@v1.0.7
with:
lre_action: ExecuteLreTest
lre_description: running new yaml test
lre_server: myserver.mydomain.com/?tenant=fa128c06-5436-413d-9cfa-9f04bb738df3
lre_https_protocol: true
lre_authenticate_with_token: false
lre_domain: DANIEL
lre_project: proj1
lre_test: 176
lre_test_instance: AUTO
lre_timeslot_duration_hours: 0
lre_timeslot_duration_minutes: 30
lre_post_run_action: Collate and Analyze
lre_vuds_mode: false
lre_trend_report: ASSOCIATED
lre_status_by_sla: false
lre_output_dir: ${{ github.workspace }}
- name: Upload build artifacts
uses: actions/upload-artifact@v4
with:
name: build-artifacts
path: ${{ github.workspace }}/LreResultSynchronize scripts from repository workspace (located in 'scripts' folder) to OpenText Enterprise Performance Engineering (WorkspaceSync)
name: Synchronize scripts to OpenText Enterprise Performance Engineering
on:
workflow_dispatch:
jobs:
workspace-sync:
runs-on: ubuntu-latest
permissions:
contents: read # required for checkout and git-diff detection
actions: read # required for incremental sync since last successful build
env:
lre_username: ${{ secrets.LRE_USERNAME }}
lre_password: ${{ secrets.LRE_PASSWORD }}
GITHUB_TOKEN: ${{ github.token }} # required for incremental sync to query last successful run
steps:
- name: Checkout code
uses: actions/checkout@v6
with:
fetch-depth: 0
- name: Setup Java
uses: actions/setup-java@v5
with:
distribution: adopt
java-version: '17'
- name: Set up Node.js
uses: actions/setup-node@v6
with:
node-version: '25'
- name: Synchronize scripts
uses: MicroFocus/lre-gh-action@v1.0.7
with:
lre_action: WorkspaceSync
lre_description: synchronize scripts from workspace
lre_server: myserver.mydomain.com/?tenant=fa128c06-5436-413d-9cfa-9f04bb738df3
lre_https_protocol: true
lre_authenticate_with_token: false
lre_domain: DANIEL
lre_project: proj1
lre_workspace_dir: ${{ github.workspace }}/scripts
lre_runtime_only: true
lre_workspace_sync_success_threshold: 70
lre_workspace_sync_delete_removed_scripts: false
lre_enable_stacktrace: true
- name: Upload build artifacts
uses: actions/upload-artifact@v7
with:
name: build-artifacts
path: '${{ github.workspace }}/scripts/logs'Copy your YAML files to a folder in your Git repository (YAML files under the root of the Git repository will be ignored). The plugin will create the test in the project according to:
- The file name (without extension) which will be used as test name.
- The location of the file in the Git repository which will be the location of the test under the root folder ('Subject') in the Test Management tree.
- The content of the YAML file which must be composed according to the parameters described in the tables below.
Note:
- All parameters must be in lowercase.
- When a backslash () occurs in a value provided to a parameter (for example, a folder separator in a file path), a double backslash (\) must be used instead.
- This feature is supported with Performance Center 12.61 and later versions.
Root parameters of the YAML file:
| Parameter | Description | Required |
|---|---|---|
| controller | Defines the Controller to be used during the test run (it must be an available host in the project). If not specified, a Controller will be chosen from the different controllers available in the project. | No |
| lg_amount | Number of load generators to allocate to the test (every group in the test will be run by the same load generators). | Not required if each group defined in the 'group' parameter defines the load generators it will be using via the 'lg_name' parameter (see 'group' table below). |
| group | Lists all groups or scripts defined in the test. The parameters used in each group are specified in the 'group' table below. | Yes |
| scheduler | Defines the duration of a test, and determines whether virtual users are started simultaneously or gradually. See the 'scheduler' table below. | No |
| lg_elastic_configuration | Defines the image to be used in order to provision load generators. See the 'lg_elastic_configuration' table below. Available from Performance Center 12.62 and plugin version 1.1.1. | Yes, if a load generator is defined to be provisioned from a Docker image. |
| automatic_trending | Defines association to existing trend report. | No |
group:
| Parameter | Description | Required |
|---|---|---|
| group_name | Name of the group (it must be a unique name if several groups are defined). | Yes |
| vusers | Number of virtual users to allocate to the group for running the script. | Yes |
| script_id | ID of the script in the project. | Not required if the 'script_path' parameter is specified. |
| script_path | Path and name of the script to be added to the group, separated by double backslashes (\). For example "MyMainFolder\MySubFolder\MyScriptName'. Do not include the root folder (named "Subject"). | Not required if 'script_id' parameter is specified |
| lg_name | List of load generators to allocate to the group for running the script. The supported values are: - The hostname of an existing load generator allocated as a host. - "LG" followed by a number, to use an automatically matched load generator (recommended). - "DOCKER" followed by a number, to use a dynamic load generator (available from Performance Center 12.62, if your project is set to work with Docker). This option requires the 'lg_elastic_configuration' parameter to be defined (see the 'lg_elastic_configuration' table below). |
No |
| command_line | The command line applied to the group. | No |
| rts | Object defining the runtime settings of the script. See the 'rts' table below. | No |
rts:
| Parameter | Description | Required |
|---|---|---|
| pacing | Can be used to define the number of iterations the script will run and the required delay between iterations (see the 'pacing' table below). | No |
| thinktime | Can be used to define think time (see the 'thinktime' table below). | No |
| java_vm | Can be used when defining Java environment runtime settings (see the 'java_vm' table below). | No |
| jmeter | Can be used to define JMeter environment runtime settings (see the 'jmeter' table below). | No |
pacing:
| Parameter | Description | Required |
|---|---|---|
| number_of_iterations | Specifies the number of iterations to run; this must be a positive number. | Yes |
| type | Possible values for type attribute are: - "immediately": ignores 'delay' and 'delay_random_range' parameters. This is the default value when no type is specified. - "fixed delay": 'delay' parameter is mandatory. - "random delay": 'delay' and 'delay_random_range' parameters are mandatory. - "fixed interval": 'delay' parameter is mandatory. - "random interval": 'delay' and 'delay_random_range' parameters are mandatory. |
No |
| delay | Non-negative number (less than 'delay_at_range_to_seconds' when specified). | Depends on the value provided for the 'type' parameter. |
| delay_random_range | Non-negative number. It will be added to the value given to the 'delay' parameter (the value will be randomly chosen between the value given to 'delay' parameter and the same value to which is added the value of this parameter). | Depends on the value provided for the 'type' parameter. |
thinktime:
| Parameter | Description | Required |
|---|---|---|
| type | The ThinkTime Type attribute is one of: - "ignore": This is the default value when no type is specified. - "replay": Provide 'limit_seconds' parameter with value. - "modify": Provide 'limit_seconds' and 'multiply_factor' parameters with values. - "random": Provide 'limit_seconds', 'min_percentage' and 'max_percentage' parameters with values. |
No |
| min_percentage | This must be a positive number. | Depends on the value provided for the 'type' parameter. |
| max_percentage | This must be a positive number (it must be larger than the value provided for the 'min_percentage' parameter). | Depends on the value provided for the 'type' parameter. |
| limit_seconds | This must be a positive number. | Depends on the value provided for the 'type' parameter. |
| multiply_factor | The recorded think time is multiplied by this factor at runtime. | Depends on the value provided for the 'type' parameter. |
java_vm:
| Parameter | Description | Required |
|---|---|---|
| jdk_home | The JDK installation path. | No |
| java_vm_parameters | List the Java command line parameters. These parameters can be any JVM argument. Common arguments are the debug flag (-verbose) or memory settings (-ms, -mx). In addition, you can pass properties to Java applications in the form of a -D flag. | No |
| use_xboot | Boolean: Instructs VuGen to add the Classpath before the Xbootclasspath (prepend the string). | No |
| enable_classloader_per_vuser | Boolean: Loads each Virtual User using a dedicated class loader (runs Vusers as threads). | No |
| java_env_class_paths | A list of classpath entries. Use a double backslash (\) for folder separators. | No |
jmeter:
| Parameter | Description | Required |
|---|---|---|
| start_measurements | Boolean value to enable JMX measurements during performance test execution. | No |
| jmeter_home_path | Path to JMeter home. If not defined, the path from the %JMETER_HOME% environment variable is used. | No |
| jmeter_min_port | This number must be lower than the value provided in the 'jmeter_max_port' parameter. Both 'jmeter_min_port' and 'jmeter_max_port' parameters must be specified otherwise the default port values is used. | No |
| jmeter_max_port | This number must be higher than the value provided in the 'jmeter_min_port' parameter. Both 'jmeter_min_port' and 'jmeter_max_port' parameters must be specified otherwise the default port values is used. | No |
| jmeter_additional_properties | JMeter additional properties file. Use double backslashes (\) for folder separators. | No |
scheduler:
| Parameter | Description | Required |
|---|---|---|
| rampup | Time, in seconds, to gradually start all virtual users. Additional virtual users are added every 15 seconds until the time specified in the parameter ends. If no value is specified, all virtual users are started simultaneously at the beginning of the test. | No |
| duration | Time, in seconds, that it will take to run the test after all virtual users are started. After this time, the test run ends. If not specified, the test will run until completion. | No |
automatic_trending:
| Parameter | Description | Required |
|---|---|---|
| report_id | ID of the trend report to associate the test run analysis with. | No |
| max_runs_in_report | Maximum trends in a report (default is 10 if not specified). | No |
lg_elastic_configuration: (available from Performance Center 12.62 and plugin version 1.1.1)
| Parameter | Description | Required |
|---|---|---|
| image_id | This number can be retrieved from: - The Administration page (you might need to turn to your administrator, as accessing this page requires admin privileges): select the Orchestration section -> switch to Docker Images tab -> you will have the list of all available Docker images for Load Generator purposes with their ID. You can make sure the images are available to your project from the Orchestrators tab. - An OpenText Enterprise Performance Engineering REST API command applied on the project (replace the bracketed values): GET - http(s)://(PCServer):(PortNumber)/LoadTest/rest/domains/(DomainName)/projects/(ProjectName)/dockerimages/ and select any valid image not having the value 'controller' for purpose. |
Yes, if one of the load generators is defined to be provisioned from a Docker image. |
| memory_limit | This parameter can be retrieved from Application -> Test Management -> edit a test -> Press Assign LG button -> in the Elastic section, select DOCKER1 -> select the relevant image (based on the image name) -> use the values provided in the 'Memory(GB)' dropdown list (if not specified, this parameter should be ignored). | Yes, if the image is defined with resource limits |
| cpu_limit | This parameter can be retrieved from Application -> Test Management -> edit a test -> Press Assign LG button -> in the Elastic section, select DOCKER1 -> select the relevant image (based on the image name) -> use the values provided in the 'CPUs' dropdown list (if not specified, this parameter should be ignored). | Yes, if the image is defined with resource limits |
In the example below:
- The plugin automatically assigns the file name as the test name, and the folder path of the file in the Git repository is used to create the location of the test under the root folder ('Subject') in the project.
- In the content:
- Since no Controller and no load generator amount were specified, a random available Controller will be allocated to the test just before it is run and the 'lg_name' parameter specified in each group will be used.
- In the 'group' parameter:
- We added two scripts. For each, we provided a unique value in the 'group_name' parameter, and the number of virtual users to run the group.
- Since we did not know the ID of the scripts, we used the 'script_path' parameter in which we entered the script path (without "Subject") followed by the script name, and used double backslashes for separators.
- We specified the load generators that will be used by each group (in this case, load generators will automatically be matched as we use the 'LG' prefix).
- In the scheduler:
- We want all Virtual Users to be initialized gradually (45 seconds).
- We want the test to stop after 5 minutes (300 seconds).
##################################################
group:
- group_name: "TEstInt"
vusers: '20'
script_path: "plugin\\TEstInt"
lg_name:
- "LG1"
- "LG2"
- group_name: "Mtours"
vusers: '20'
script_path: "plugin\\mtours"
lg_name:
- "LG3"
- "LG4"
scheduler:
rampup: '45'
Duration: '300'
##################################################
In the example below:
- The plugin automatically assigns the file name as the test name, and the folder path of the file in the Git repository is used to create the location of the test under the root folder ('Subject') in the project.
- Since the 'controller' and the 'lg_amount' parameters are specified, the specified Controller will be used to run the test and three automatch load generators will be used and shared by all groups.
- The content of the file is defined with seven groups, all being set with the "rts" parameter:
- The "pacing" parameter is used with different options for all groups.
- The "java_vm" parameter is used for five scripts with JavaVM for protocol.
- The "thinktime" parameter is used with different options for four groups.
- The "jmeter" parameter is used for two scripts with JMeter for protocol.
- In the scheduler:
- We want all Virtual Users to be initialized gradually (120 seconds).
- We want the test to stop after 10 minutes (600 seconds).
##################################################
controller: "mycontroller"
lg_amount: 3
group:
- group_name: "JavaVuser_LR_Information_pacing_immediately_thinktime_ignore"
vusers: 50
script_id: 394
rts:
pacing:
number_of_iterations: 2
type: "immediately"
java_vm:
jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
java_vm_parameters: "java_vm_parameters"
enable_classloader_per_vuser: true
use_xboot: true
java_env_class_paths:
- "java_env_class_path1"
- "java_env_class_path2"
thinktime:
type: "ignore"
- group_name: "JavaHTTP_BigXML_pacing_fixed_delay_thinktime_replay"
vusers: 50
script_path: "scripts\\java_protocols\\JavaHTTP_BigXML"
rts:
pacing:
number_of_iterations: 2
type: "fixed delay"
delay: 10
java_vm:
jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
java_vm_parameters: "java_vm_parameters"
enable_classloader_per_vuser: true
thinktime:
type: "replay"
limit_seconds: 30
- group_name: "JavaVuser_LR_Information_immediately_pacing_random_delay_thinktime_modify"
vusers: 50
script_id: 394
rts:
pacing:
number_of_iterations: 2
type: "random delay"
delay: 10
delay_random_range: 20
java_vm:
jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
java_vm_parameters: "java_vm_parameters"
enable_classloader_per_vuser: true
java_env_class_paths:
- "java_env_class_path1"
- "java_env_class_path2"
thinktime:
type: "modify"
limit_seconds: 30
multiply_factor: 2
- group_name: "JavaHTTP_BigXML_pacing_fixed_interval_thinktime_random"
vusers: 50
#script_id: 392
script_path: "scripts\\java_protocols\\JavaHTTP_BigXML"
rts:
pacing:
number_of_iterations: 2
type: "fixed interval"
delay: 10
java_vm:
jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
java_vm_parameters: "java_vm_parameters"
enable_classloader_per_vuser: true
java_env_class_paths:
- "java_env_class_path1"
- "java_env_class_path2"
thinktime:
type: "random"
limit_seconds: 30
min_percentage: 2
max_percentage: 3
- group_name: "JavaHTTP_BigXML_pacing_random_interval"
vusers: 50
script_path: "scripts\\java_protocols\\JavaHTTP_BigXML"
rts:
pacing:
number_of_iterations: 2
type: "random interval"
delay: 10
delay_random_range: 20
java_vm:
jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
java_vm_parameters: "java_vm_parameters"
enable_classloader_per_vuser: true
java_env_class_paths:
- "java_env_class_path1"
- "java_env_class_path2"
- group_name: "Mtours_pacing_random_interval"
vusers: 50
script_path: "scripts\\Mtours"
rts:
pacing:
number_of_iterations: 2
type: "random interval"
delay: 10
delay_random_range: 20
jmeter:
start_measurements: true
jmeter_home_path: "c:\\jmeter"
jmeter_min_port: 2001
jmeter_max_port: 3001
jmeter_additional_properties: "jmeter_additional_properties"
- group_name: "Mtours_pacing_random_interval_Jmeter_default_port"
vusers: 50
script_path: "scripts\\Mtours"
rts:
pacing:
number_of_iterations: 2
type: "random interval"
delay: 10
delay_random_range: 20
jmeter:
start_measurements: true
scheduler:
rampup: 120
duration: 600
##################################################