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

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:

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

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.frontline.poolName") // pool is the former name of location
val baseUrl = if (locationName == "Europe - Paris") "https://example.fr" else "https://example.com"

Edit this page on GitHub

← Profile
Package Configuration →