Package Generation

    Gatling Enterprise Gatling Versions

    Gatling Enterprise actually uses custom versions of the Gatling components. Those binaries are not open source and their usage is restricted to Gatling Enterprise.

    When you deploy simulations with Gatling Enterprise, it replaces your Gatling OSS dependencies with their custom counterparts.

    Configuring Gatling Projects

    You can configure your project to allow Gatling Enterprise to build it from the source code, or you can decide to publish a binary package yourself and let Gatling Enterprise retrieve it.

    Either way, you will need to configure a project using one of the supported build tools, with the corresponding Gatling plugin. To set up you project, please refer to the documentation pages of the respective plugins:

    Once your project is ready, you can then configure a repository and a simulation.

    Note on Feeders

    A typical mistake with Gatling and Gatling Enterprise is to rely on having an exploded maven/gradle/sbt project structure and try loading files from the project filesystem.

    This filesystem structure will be gone once Gatling Enterprise will have compiled your project and uploaded your binaries on the injectors.

    If your feeder files are packaged with your test sources, you must resolve them from the classpath. This way will always work, both locally and with Gatling Enterprise.

    // incorrect
val feeder = csv("src/test/resources/foo.csv")

// correct
val feeder = csv("foo.csv")

    Specific Gatling Features

    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 a CSV file contains 1000 entries, and 3 Gatling nodes, the entries will be distributed the following way:

    • 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 Injector Location in Simulation

    When running a distributed test from multiple locations, you could be interested in knowing where a given injector is deployed in order to trigger specific behaviors depending on location.

    For example, you might want to hit https://mydomain.co.uk baseUrl if injector is deployed on AWS London, and https://mydomain.com otherwise.

    You can resolve in your simulation code the name of the pool a given injector is deployed on:

    val poolName = System.getProperty("gatling.enterprise.poolName")
val baseUrl = if (poolName == "London") "https://domain.co.uk" else "https://domain.com"

    Edit this page on GitHub

    ← User profile
    Repositories configuration →