Gatling Enterprise 1.13 Highlights

Gatling Enterprise 1.13 introduce support for multiple versions of Gatling and performance fixes

Gatling Enterprise 1.13

Gatling 3.3, 3.4 and 3.5 generations support

Gatling Enterprise 1.13 is compatible with the 3 latest Gatling generations.

Key New Features

We’ve changed the way duration events are aggregated.

Prior to Gatling Enterprise 1.13, those stats were aggregated by start timestamp, which could cause a lot of memory and CPU usage without any proven benefit.

Those stats are now aggregated by end timestamp, which results in a way more sound memory and CPU usage and paves the way for more long duration metrics that could be implemented in a future release, such as scenario duration.

We’ve also introduced hard limits on the number of metrics that a given test run can generate. In some situations, a test could generate way too many metrics and cause the whole Gatling Enterprise instance to crash.

Key Bug Fixes

We’ve fixed some important bugs that could cause injectors and Gatling Enterprise server to not be in sync, causing long tests to abnormally crash.

Please check the Release Note for the full list of bug fixes.

Gatling 3.5.0

Scala 2.13

Scala 2.13.0 was released in June 2019 and Scala 3 is expected soon, so it was critical that Gatling stopped lagging behind.

Gatling 3.5.0 is compiled against Scala 2.13, meaning that it’s not binary compatible with the previous releases.

Please check the migration guide for more information about how to upgrade your tests. The most noticeable impact is probably refreshing projects imported in your IDE.

Please also check the full release note for more details about the content of this release.

Key New Features

  • support for Scala case classes in Gatling Expression Language and jsonStringify
  • ability to use Pebble templates for multipart parts
  • ability to provide regex patterns to useAllLocalAddresses to only use desired local addresses

Key Bug Fixes

  • children scenarios not being triggered when parent doesn’t generate any load. This can typically happen when using a parent scenario to initialize something with one single virtual user while running a cluster of injector so only one node get the single user.
  • feeders configured with batch still loading the first batch, making them unsuitable for lazy loading while the file is actually populated at runtime from a parent scenario.

Operations

Old Binaries Distribution Platform Upcoming Shutdown

Edit this page on GitHub