Optional configurations for simulations
Optional configurations for simulations in Gatling Enterprise.
Optional configurations for simulations
In addition to the standard configuration options, Gatling Enterprise provides several optional configurations for simulations. These options allow you to customize the behavior of your simulations to better suit your testing needs.
Load generator parameters
You can specify load generator parameters in your simulation configuration. This is useful for scenarios where you need to customize the behavior of the load generator, such as adjusting the number of virtual users or the ramp-up time.
This step allows you to define the Java system properties or JS parameters and environment variables used when running this particular simulation. Properties/variables entered here are in addition to the default parameters, unless you ignore the defaults.
If have the same key in your simulation configuration and the the default load generator parameters table the simulation value is used and overrides the default.
sensitive., and environment variables if you prefix them with SENSITIVE_.You can configure the gatling.enterprise.groupedDomains Java System property to group connection stats from multiple subdomains and avoid memory issues when hitting a very large number of subdomains.
For example, setting this property as .foo.com, .bar.com will consolidate stats for sub1.foo.com, sub2.foo.com, sub1.bar.com, sub2.bar.com into *****.foo.com and *****.bar.com.
System properties can be retrieved in your Gatling simulation with System.getProperty("YOUR_PROPERTY_KEY").
Environment variables can be retrieved in your Gatling simulation with System.getEnv("YOUR_ENV_VAR_KEY").
Time window
You can configure ramp-up and ramp-down time windows to be excluded from computed assertions. This is typically useful when you know that at the beginning of your test run you expect higher response times than when your system is warm (JIT compiler has kicked in, autoscaling has done its work, caches are filled, etc.) and don’t want them the warm-up time to cause your assertions to fail.
- Ramp Up: the number of seconds you want to exclude at the beginning of the run.
- Ramp Down: the number of seconds you want to exclude at the end of the run.
Stop criteria
In this step, you can configure specific stop criteria to end the run earlier if certain thresholds are exceeded. This is particularly useful for terminating test runs once key performance metrics exceed acceptable limits.
Each stop criterion must include:
- Metric: The metric for which the stop criterion is evaluated. (Mean CPU, Global Error Ratio or Global Response Time)
- Threshold: The value that, when reached or exceeded, will trigger the stop condition. (eg: over 30% / 300ms on 99.9 percentile)
- Timeframe (in seconds): The period during which the metric must exceed the threshold for the entire duration to trigger the stop (eg: last 60 seconds).
You can base stop criteria on the following metrics:
- Mean CPU Usage: The average CPU usage of the load generators, measured as a percentage.
- Global Error Ratio: The percentage of failed requests across all test scenarios.
- Global Response Time: The response time of all requests, measured at a specific percentile, in milliseconds.
Acceptance criteria (no-code simulations only)
Gatling Enterprise allows you to define acceptance criteria for your simulations. This includes specifying thresholds for key performance indicators (KPIs) such as response time, throughput, and error rate. By setting clear acceptance criteria, you can ensure that your application meets the desired performance standards before it is deployed. For test-as-code simulations, these criteria can be defined in the simulation code itself, while for no-code simulations, they can be configured through the user interface.