Package Generation
Generate a package from your Gatling bundle or with a Maven, SBT, or Gradle project.
Generating Packages for Gatling Enterprise
Gatling Enterprise deploys packages containing your compiled Simulations and resources. Those packages have to be generated upstream, using one of the methods below, before you can run them with Gatling Enterprise.
Gatling Enterprise is compatible with Gatling version from 3.3 to 3.8 included.
Gatling zip bundle
Once you have created a simulation you want to upload, run the script gatling.sh
(on Linux or macOS) or
gatling.bat
(on Windows), found in the bin
directory of your unzipped Gatling bundle and then select choice 3
. This will generate a
target/package.jar
file. You can then upload this file in the Packages section.
$ ./bin/gatling.sh
Do you want to run the simulation locally, on Gatling Enterprise, or just package it?
Type the number corresponding to your choice and press enter
[0] <Quit>
[1] Run the Simulation locally
[2] Run the Simulation on Gatling Enterprise Cloud
[3] Package the Simulation for Gatling Enterprise
3
You can also create a package and upload it in a single command, always using the same script, but selecting choice 2
. You must have already configured a package
(copy the package ID from the Packages table). You also need an API token with
appropriate permissions to upload a package.
Run the script:
$ ./bin/gatling.sh --package-id YOUR_PACKAGE_ID --api-token YOUR_API_TOKEN
Alternatively, the API token can be set with the environment variable GATLING_ENTERPRISE_API_TOKEN
:
$ export GATLING_ENTERPRISE_API_TOKEN=YOUR_API_TOKEN
$ ./bin/gatling.sh --package-id YOUR_PACKAGE_ID
Finally, you can get the list of all the available options with the --help
option:
$ ./bin/gatling.sh --help
3.8
. If you’re using an older version, you’ll have to upgrade.Maven, Gradle or SBT project
To set up you project, and to learn how to use you preferred build tool to upload your simulations to Gatling Enterprise Cloud, please refer to the documentation pages of the respective plugins:
- Gatling plugin for Maven (for Java, Kotlin and Scala)
- Gatling plugin for Gradle (for Java, Kotlin and Scala)
- Gatling plugin for SBT (for Scala)
io.gatling.frontline:frontline-maven-plugin
, io.gatling.frontline:frontline-gradle-plugin
or
io.gatling.frontline:sbt-frontline
) in your build, we recommend removing it and updating to the latest version of the
Gatling plugin instead.Note on Feeders
A typical mistake with Gatling and Gatling Enterprise is to rely on having an exploded Maven/Gradle/SBT project structure, and to try to load files from the project filesystem.
This filesystem structure will not be accessible once your project has been packaged and deployed to Gatling Enterprise.
If your feeder files are packaged with your test sources, you must resolve them from the classpath. This will work both when you run simulations locally and when you deploy them to Gatling Enterprise.
// incorrect
val feeder = csv("src/test/resources/foo.csv")
// correct
val feeder = csv("foo.csv")
Load Sharding
Injection rates and throttling rates are automatically distributed amongst nodes.
However, Feeders data is not automatically sharded, as it might not be the desired behavior.
If you want data to be unique cluster-wide, you have to explicitly tell Gatling to shard the data, e.g.:
val feeder = csv("foo.csv").shard
Assuming the CSV file contains 1000 entries, and you run your simulation on 3 Gatling nodes, the entries will be distributed as follows:
- First node will access the first 333 entries
- Second node will access the next 333 entries
- Third node will access the last 334 entries
shard
is available in Gatling OSS DSL but is a noop there. It’s only effective when running tests with Gatling Enterprise.Resolving Load Generator Location in Simulation
When running a distributed test from multiple locations, you could be interested in knowing where a given load generator is deployed in order to trigger specific behaviors depending on the location.
For example, you might want to hit https://example.fr
if the load generator is deployed in the Europe - Paris
location, and https://example.com
otherwise.
In your simulation code, you can resolve the name of the location in which the load generator running the code is deployed:
val locationName = System.getProperty("gatling.enterprise.poolName") // pool is the former name of location
val baseUrl = if (locationName == "Europe - Paris") "https://example.fr" else "https://example.com"