Files Manager¶

This page allows you to manage files:

CSV variables content,
POST Http request bodies,
Kerberos configuration files,
.sh scripts,
hosts file to be be appended at the end of the load generator’s hosts file (during validation and runtime).
JMeter Plugins jar files.

Files list¶

Files Manager

The Files page is basically a list and as such it features all the usual possibilities as described in the dedicated section about lists.

The Current and maximum file size for this project are displayed on top, these settings can be changed through the configuration files of your On premise Infra.

Note

Files might be deployed to different folders prior to the execution. You can find out more on the test startup process page.

Upload files¶

File Selector

Click Upload new files or drag and drop files in the bottom panel to upload one or several files into your project.

Files with the exact same name (case sensitive) will override the existing files.

Info

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

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 keep alive TTL¶

The default keep alive TTL in JMeter is 60 seconds. Some applications might be configured to consider the HTTP connection expired after less than 60 seconds of inactivity.

In that case JMeter might try to reuse an expired connection, thus getting an error. To prevent this, you can configure JMeter to consider the HTTP connection expired after a shorter period of inactivity:

before-test.sh:

#!/usr/bin/env bash

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

echo "httpclient4.time_to_live=1"  >> ${USER_PROPS}

Warning

Changing this setting will cause JMeter to create more connections than it usually would. Thus generating a different load to your servers. Make sure to only change it when you know for sure that the TTL must be lower.

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}

Disable SNI¶

This script allows you to disable Server Name Indication in java 7+. This is useful in order to fix the following exception: "handshake alert: unrecognized_name".

before-test.sh:

#!/usr/bin/env bash
SYS_PROPS=${JMETER_HOME}/bin/system.properties
echo "jsse.enableSNIExtension=false"  >> ${SYS_PROPS}

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:

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.

Print Environment variables¶

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"