Where Gatling fits on a long engagement.

Scenarios as code is the property that keeps Gatling suites alive. They live in the repository, they are reviewed like any other change, and they refactor properly. That is a meaningful advantage over tools whose test plans are XML artefacts nobody can diff.

Its asynchronous engine generates substantially more load per machine than thread-per-user tools, which matters both for cost and for accuracy — fewer machines means less chance that the generator is the constraint. The trade-off is a JVM language requirement that not every team has.

What an assigned team does with Gatling.

Performance work is most effective when the same people own the scenarios and interpret the results. Handing a report to a team that did not design the test produces numbers without the context needed to act on them.

That is why load testing is assigned as standing capacity rather than commissioned as an exercise, under outsource qa testing.

What we use Gatling for.

  • Scenarios reviewed like application code Load tests in the repository, refactored and diffed rather than maintained as opaque artefacts.
  • High load from modest infrastructure Efficient generation, so the test measures the system rather than the generator.
  • Reports detailed enough to act on Percentile distributions over time that identify where a system degrades, not just that it did.

How Gatling capacity is assigned.

Load scenarios are version-controlled alongside the application, and the people who design them interpret the results. How that responsibility is framed is set out in how an assignment runs.

Tell us what your roadmap needs Gatling for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

Loading the contact form… You can also email hello@azendo.co.

We reply within one working day. No obligation, and no newsletter.