Skip to content

Files Manager

The Files manager tool is available on the left menu of the Design view, in the Tools section or from the upper menu:

files-menu

Files list

This menu lets you upload and delete files. These files can be:

Files Manager

Note

All relevant files will be uploaded to the load generator under a resources/ folder. Except JAR files since they must be in lib/ext/ instead. If you have any static reference to a file in your script, make sure to update it using this relative path after import. For example: resources/myCSVfile.csv.

Upload a file

You can upload files simply by drag and dropping them in the Drop files here zone or by clicking on the Choose Files button.

Files are automatically added to the list, and a progress bar is displayed to inform you the the upload progress.

You can upload Zipped files that OctoPerf will automatically unzip after upload by using the .unzipme.zip suffix:

Unzipme

Info

You can upload multiple files at the same time. Zipped or not.

To replace a file content, simply upload the new file with the same name. The one already present in the files list is overwritten.

Delete a file

You can delete files simply by clicking on the Delete button in the list:

Warning

You can actually remove or replace a file that is used in a CSV variable or a POST request body. To make sure it does not break your virtual user execution you may run a validation before launching a real test.

Select a file

You can select or directly upload files from the CSV Variable panel or POST request bodies:

File Selector

Selecting an existing file is done using the select box. If you use many files in your project you can type the name of the file you are looking for to filter the displayed file.

Simply click on any filename to select it.

To upload a file click on the plus button located at the right of the selector. A Choose File button appears. Click on it and select a local file. It is automatically uploaded and selected.

Note

If there are no files available in the current project, only the file upload option is visible. Filters may apply for the files you can select or upload. For example CSV variable only accept .csv and .txt files.

Script Examples

Two types of sh scripts can be uploaded in the Files section and be automatically executed by OctoPerf:

  • before-test.sh: bash script (using #!/usr/bin/env bash shebang) to run before the test is being executed. Runs on each load generator,
  • after-test.sh: bash script (using #!/usr/bin/env bash shebang) to run after the test is being executed. Runs on each load generator.

Note

More information on when these scripts are triggered can be found in the test startup process page.

JDBC configurations

Remove outdated driver jar

The following script removes the old mongodb driver from JMeter lib/ folder:

before-test.sh:

#!/usr/bin/env bash
rm -f "${JMETER_HOME}/lib/mongo-java-driver-2.11.3.jar"

It can be convenient to use if some JAR files you need conflict with the existing JMeter JAR files.

Change timezone

The underlying JDBC driver may have trouble dealing with dates comparisons if your database is using a different timezone than UTC.

The following script will change OctoPerf's agent timezone to match yours:

before-test.sh:

#!/usr/bin/env bash
export JVM_ARGS="${JVM_ARGS} -Duser.timezone=GMT+2"

We encountered this issue with Postgresql JDBC driver.

Edit JMeter settings

Add a new user property

Scripts can also be used to add JMeter properties before the tests starts. For instance here to add retries on network packet to get rid of connection reset messages:

before-test.sh:

#!/usr/bin/env bash

USER_PROPS=${JMETER_HOME}/bin/user.properties

echo "httpclient4.retrycount=10"  >> ${USER_PROPS}
echo "httpclient4.idletimeout=120"  >> ${USER_PROPS}

Warning

Increasing retry and timeout may remove the issue from the test results but it does not actually fix it. Connectivity issues during a load test strongly indicates you reached a bottleneck, try to investigate.

Edit an existing user property

In case you want to edit a property that already exists, just adding it at the end of the file may not be enough. This script example will remove a line from user.properties but it can be adapted to any situation:

before-test.sh:

#!/usr/bin/env bash

sed -e '/httpsampler.embedded_resources_use_md5=true/ s/^#*/#/' -i ${JMETER_HOME}/bin/user.properties

Log Garbage Collector Activity

This script allows you to log JMeter's Garbage Collector activity for further debugging when you suspect having memory issues.

before-test.sh:

#!/usr/bin/env bash
export JVM_ARGS="${JVM_ARGS} -verbose:gc -Xloggc:${JMETER_HOME}/gc.log"
echo ${JVM_ARGS}

after-test.sh:

#!/usr/bin/env bash
mv ${JMETER_HOME}/gc.log ${JMETER_HOME}/${HOST_NAME}.gc.log
uploadFile ${JMETER_HOME}/${HOST_NAME}.gc.log

The GC log files are then be available along with the JMeter logs in the report.

Disable TLS versions

This script allows you to force a particular version of TLS, and disable other versions at the same time. For this to work, an additional configuration file must be added to the Files menu.

before-test.sh:

#!/usr/bin/env bash
export JVM_ARGS="${JVM_ARGS} -Djava.security.properties=${JMETER_HOME}/resources/disabled_tlsv1.properties"
echo ${JVM_ARGS}

Activate JMeter debug logs

This script allows you to override the log4j2.xml file of JMeter inside OctoPerf before the test. Note that you must provide the edited log4j2.xml inside the Files menu for this to work.

before-test.sh:

#!/usr/bin/env bash
cp ${JMETER_HOME}/resources/log4j2.xml ${JMETER_HOME}/bin/log4j2.xml

Custom certificate

This script will be executed just before the test starts and right after all load generators are created. It is a good way to execute a configuration Like editing the system.properties file. Some properties must be in this file instead of the user.properties file that you can edit through runtime properties.

JKS certificate

In this example we configured JMeter to use a custom keystore so that our virtual users will send a specific JKS certificate:

before-test.sh: 

#!/usr/bin/env bash

SYSTEM_PROPS=${JMETER_HOME}/bin/system.properties

echo "javax.net.ssl.keyStore=${JMETER_HOME}/resources/myCert.jks"  >> ${SYSTEM_PROPS}
echo ""  >> ${SYSTEM_PROPS}
echo "javax.net.ssl.keyStorePassword=myPassword"  >> ${SYSTEM_PROPS}

PFX Certificate

It works with PFX certificates as well you just need to specify the keystoreType:

before-test.sh:

#!/usr/bin/env bash

SYSTEM_PROPS=${JMETER_HOME}/bin/system.properties

echo "javax.net.ssl.keyStore=${JMETER_HOME}/resources/myCert.pfx"  >> ${SYSTEM_PROPS}
echo ""  >> ${SYSTEM_PROPS}
echo "javax.net.ssl.keyStorePassword=myPassword"  >> ${SYSTEM_PROPS}
echo ""  >> ${SYSTEM_PROPS}
echo "javax.net.ssl.keyStoreType=pkcs12"  >> ${SYSTEM_PROPS}
This way when JMeter starts it will take these settings into account.

Use a different certificate per runtime profile

Since the before-test.sh file is the same for then entire test, it is sometimes difficult to provide a different value for each runtime profile inside a single test. To address that it is possible to use properties. The following script will use a property as defined on the runtime profile:

before-test.sh:

SYSTEM_PROPS=${JMETER_HOME}/bin/system.properties
local KEYSTORE=$(getProperty "${JMETER_USER_PROPERTIES}" "javax.net.ssl.keyStore")
local PASSWORD=$(getProperty "${JMETER_USER_PROPERTIES}" "javax.net.ssl.keyStorePassword")

echo "javax.net.ssl.keyStore=${JMETER_HOME}/resources/${KEYSTORE}"  >> ${SYSTEM_PROPS}
echo ""  >> ${SYSTEM_PROPS}
echo "javax.net.ssl.keyStorePassword=${PASSWORD}"  >> ${SYSTEM_PROPS}

Here's what the runtime profile looks like:

properties

Use a certificate store with multiple certificates

It is possible for each virtual user to use a different certificate from a certificate store but some properties must be set in order to do that:

before-test.sh:

#!/usr/bin/env bash

SYSTEM_PROPS=${JMETER_HOME}/bin/system.properties
echo "javax.net.ssl.keyStore=${JMETER_HOME}/resources/keystore.jks"  >> ${SYSTEM_PROPS}
echo ""  >> ${SYSTEM_PROPS}
echo "javax.net.ssl.keyStorePassword=changeit"  >> ${SYSTEM_PROPS}

JMETER_PROPS=${JMETER_HOME}/bin/jmeter.properties
echo "https.keyStoreStartIndex=0"  >> ${JMETER_PROPS}
echo "https.keyStoreEndIndex=30"  >> ${JMETER_PROPS}
echo "https.keyStoreCertAliasVarName=${keystore}"  >> ${JMETER_PROPS}
echo "https.keyStorePreload=true"  >> ${JMETER_PROPS}
  • keyStoreStartIndex : Index of first certificate to use,
  • keyStoreEndIndex : Index of last certificate to use, -1 to use all certificates,
  • keyStoreCertAliasVarName : Leave empty to use certificates sequentially, or specify certificate alias to use through a variables (like a CSV variable),
  • keyStorePreload : Should the certificate be preloaded.

Uploading a CSV to Test Logs

This script will be executed just before the test ends and all load generators are destroyed. It is a good way to execute a final action, or just save information stored on the load generators during the tests. For instance it can be used to save a CSV file created through a script to the OctoPerf report logs.

after-test.sh:

#!/usr/bin/env bash
mv file.csv ${HOST_NAME}.file.csv
uploadFile ${HOST_NAME}.file.csv
Here we use mv to add the load generator hostname to the file name. This way when we upload it to OctoPerf with uploadFile if there are several load generators, the file is not overwritten. It will then be available along with the JMeter logs in the report.

Warning

The uploadFile command will gzip your file and remove the local copy. Be careful if using it in a before-test.sh script or with a file that must be reused at a later stage.

Upload OctoPerf JMX to test logs

after-test.sh:

#!/usr/bin/env bash
mv ${JMETER_HOME}/scenario.jmx ${JMETER_HOME}/${HOST_NAME}.scenario.jmx
uploadFile ${JMETER_HOME}/${HOST_NAME}.scenario.jmx

Similarly to uploading a CSV, this script will upload the JMX file that was executed on each load generator. This can be interesting for debugging purposes or if you are not sure how OctoPerf will interpret some of your settings.

Warning

The uploadFile command will gzip your file and remove the local copy. If you upload the JMX in a before-test.sh script, JMeter will not be able to run.

This script will be executed just before the test starts and right after all load generators are created. It will display all environment variables and their values. Can be used for debugging.

before-test.sh:

#!/usr/bin/env bash
printenv

Count Lines of a CSV File

You might want to ensure that your CSV file has enough values to conduct your load test, especially if you specified the Stop VU on EOF policy on your variable. This script count the number of lines for the file myfile.csv.

before-test.sh: 

#!/usr/bin/env bash
wc -l "${JMETER_HOME}/resources/myfile.csv"