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.
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.
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:
Simply drop the file in the JMX area or use the Upload new JMX file button.
Then import all resources that your script may need to run, please refer to the Files documentation for more information.
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:
- HTTP Request Sampler,
- And JSR223 Sampler : BeanShell are converted to JSR with beanShell language
- Simple Controller,
- Random Controller,
- Throughput Controller,
- If Controller,
- While Controller,
- ForEach Controller,
- Transaction Controller,
- Module Controller.
- CSV Data Set Config,
- DNS Cache Manager,
- HTTP Authorization Manager,
- HTTP Cache Manager,
- HTTP Cookie Manager,
- HTTP Header Manager,
- User Defined Variables,
- Random Variable.
- Constant Timer,
- Uniform Random Timer,
- Constant Throughput Timer.
- JSR223 PreProcessor: BeanShell is converted to JSR with BeanShell language.
- Regular Expression Extractor,
- JSON Path Extractor,
- CSS/JQuery Extractor,
- XPATH1 Extractor,
- XPATH2 Extractor,
- JSR223 PostProcessor : BeanShell is converted to JSR with BeanShell language.
- Standard set,
- And Selenium WebDriver.
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 Actions lets you edit the configuration of the associated JMeter test element (here a CSV dataset config).
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.
Make sure to update file paths to point to the
resources/ folder and provide the required files through the Files menu.
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:
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:
The other virtual user will be a standard JMeter user but with a link action pointing to the fragment virtual user:
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 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:
The include controller points to this other 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:
In OctoPerf the result will be visually similar to the module controller:
If you want to get a real example, you can use this file: buyer.zip, import it and replay it in OctoPerf.
All JMeter plugins (even custom ones) are supported using Generic Actions.
Plugins are automatically downloaded just before runtime. In case of On-Premise Agents that would not have access to JMeter plugins, you should provide the JAR files in advance using the files manager.
Check the dedicated plugin page for more information and examples.