Skip to content

JMeter import

JMeter is an open-source load testing tool capable of recording HTTP requests through a built-in HTTP Proxy. A JMX file is a saved JMeter project in XML format. OctoPerf supports importing JMeter projects in such format.

Warning

JMeter projects often rely on external files (i.e. CSV files used in datasets or plugins). Be sure to upload them using the Files Menu after you import your JMX.

Record

To record a virtual user with JMeter, please follow the JMeter recording guide provided by the Apache Foundation.

Create Virtual User: Import JMX

Upload the JMeter JMX file to create a virtual user:

Create Virtual User from JMX

Simply drop the file in the JMX area or use the Choose File button. The download starts automatically.

Note

You may select Download resources automatically if you want OctoPerf to remove the static resources requests (images, JavaScript and Css files, etc.). These requests will then be downloaded dynamically during runtime.

Then import all resources that your script may need to run:

Import Resources

Please refer to the Files documentation for more information.

Warning

Some actions are not directly included in the generated Virtual Users after importing a JMeter JMX file:

  • A Virtual User is created for each ThreadGroup, but the execution configuration (number of simulated users, duration, cookies, cache, dns, etc.) takes place in the runtime scenarios in OctoPerf.
  • Constant variables, Random variables and CSV DataSets are imported in the variables section of your project.
  • Servers, protocol, port and their Authorization configuration are imported in the servers section of your project. For security reasons, protocol and port cannot be left empty like in JMeter, in most situations OctoPerf will be able to extrapolate the proper values for both, but if that process fails you can change them from the server menu.
  • All actions related to test recording (i.e. RecordingController) or test results (i.e. ResultAction or ResultCollector) are ignored as OctoPerf comes with its own results and reports.
  • Configuration elements that are not inside a threadgroup may not be imported if they are not in the list of natively supported actions. Typically a JDBC Connection outside of its threadgroup will not be imported.

Natively supported actions

The following elements are natively supported in OctoPerf, all others will be imported as generic actions. Each one of them is linked to its OctoPerf equivalent so that you can check how they will translate in OctoPerf:

Samplers:

Controllers:

Config elements:

Assertions:

Timers:

  • Constant Timer,
  • Uniform Random Timer,
  • Constant Throughput Timer.

Pre-processors:

Post-processors:

Backend listeners:

Plugins:

Generic actions

Most commonly used test elements are supported natively: a dedicated Virtual User action is created for each one.

All other relevant JMeter test elements will be imported as Generic Actions:

Generic JMeterAction

Generic Actions lets you edit the configuration of the associated JMeter test element (here a BSF Post Processor).

However, there are a few limitations:

  • Generic Actions cannot be added to a Virtual User, you can only duplicate existing ones.
  • Their configuration can only be edited, not extended.

At runtime, the Generic Action is converted back to its associated JMeter test element. So you should ensure that it does not break the execution of the test by validating your virtual user.

If you think a test element deserves to be supported natively in OctoPerf, please send us a mail at support@octoperf.com.

Warning

Make sure to update file paths to point to the resources/ folder and provide the required files through the Files menu.

Module controllers

JMeter test fragments and module controllers can also be imported. To guarantee that they will work in every situation, we had to restrict module controllers usage so that they can only point to a fragment. In JMeter it would look like this:

JMeter Fragments

And the result of importing such a JMX would be two virtual users, one of them being of "Test Fragments" type and containing the fragments:

Octoperf Fragments

The other virtual user will be a standard JMeter user but with a link action pointing to the fragment virtual user:

Fragments link action

Upon runtime the Buyer virtual user will behave exactly as in JMeter and if there are other virtual users using the same fragments we will be able to properly share it with them as well. This is the main reason why we have to restrict module controller usage to fragments, since otherwise we cannot determine what is required for each virtual user to run properly.

Include controllers

Include controllers behave slightly differently than module controllers in that they point to another JMeter JMX. Since OctoPerf imports the JMX itself, it would work to just upload all the JMX files because the relation between them would be lost.

It is still possible to import them but you must provide a .zip file containing all the relevant JMX files. Let's take an example where we have a main JMX like this one with a single include controller:

Main.jmx

The include controller points to this other JMX:

Sub.jmx

To be properly imported in OctoPerf you must provide a .zip file like this one. The path to all includes must be the same as specified in JMeter, typically with sub folders like this:

Zip structure

In OctoPerf the result will be visually similar to the module controller:

include-octoperf-structure

If you want to get a real example, you can use this file: buyer.zip, import it and replay it in OctoPerf.

JMeter plugins

Plugins

All JMeter plugins (even custom ones) are supported using Generic Actions.

You simply need to upload the associated .JAR files using the files manager.

Note

Plugins are automatically downloaded just before runtime so unless you use a custom one you should not have to upload the associated .jar files manually. In case of On-premise load generators that would not have access to JMeter plugins, you should provide the JAR files in advance.

HTTP2

When using JMeter's HTTP2 Plugin, you may encounter the following issue:

java.util.concurrent.ExecutionException: java.lang.IllegalStateException: No Client ALPNProcessors!
    at org.eclipse.jetty.util.FuturePromise.get(FuturePromise.java:139)
...
Caused by: java.lang.IllegalStateException: No Client ALPNProcessors!
    at org.eclipse.jetty.alpn.client.ALPNClientConnectionFactory.<init>(ALPNClientConnectionFactory.java:54)
    at org.eclipse.jetty.http2.client.HTTP2Client.lambda$doStart$1(HTTP2Client.java:160)
....
    ... 1 more
    Suppressed: java.lang.IllegalStateException: org.eclipse.jetty.alpn.openjdk8.client.OpenJDK8ClientALPNProcessor@2eb39ac9 not applicable for java 11.0.12
        at org.eclipse.jetty.alpn.openjdk8.client.OpenJDK8ClientALPNProcessor.init(OpenJDK8ClientALPNProcessor.java:50)
        at org.eclipse.jetty.alpn.client.ALPNClientConnectionFactory.<init>(ALPNClientConnectionFactory.java:74)
        ... 8 more

As we use Java JDK11+ on our load generators, to run tests that simulate HTTP2 request you need to:

  1. upload the jar into the Project Files,
  2. Create a before-test.sh which deletes the JDK8 APLN client jar:
#!/usr/bin/env bash
rm -f "${JMETER_HOME}/lib/jetty-alpn-openjdk8-*"
  1. upload the before-test.sh to project files,
  2. Download the Java Jetty APLN Client Jar 9.4.xx which is the same version as other jetty jars within your ${JMETER_HOME}/lib/ext folder,
  3. upload the client jar to your project files.