Gatling review: pricing, pros and cons

Gatling’s engine is built on Netty, a non-blocking network library. A virtual user is not an operating system thread parked on a socket: it is a small piece of state handed from action to action, and a pool of shared threads moves users along as responses arrive. Thread-per-user tools such as JMeter spend memory and context switches on every waiting user; Gatling spends them only on work, which is why it reaches high concurrency on modest hardware. Version 3.12 removed the Akka library that once provided the actor model and replaced it with an executor and a multiple-producer, single-consumer queue as each actor’s mailbox. The design has one rule you must respect: functions you write run on those shared threads, so a blocking call inside one, such as a remote API call, stalls users who have nothing to do with it.

A simulation class declares an HTTP protocol, one or more scenarios, and a setUp call that binds each scenario to an injection profile. The DSL objects are immutable builders: Gatling runs your class once at start-up to assemble the recipe, then executes that recipe for every virtual user. Ordinary Java, Kotlin or Scala in a builder therefore runs once. Anything that must differ per user or per iteration has to be deferred, either as an Expression Language string such as "#{orderId}" or as a function that receives the user’s Session. Only Gatling SDK methods interpret EL strings, so passing one to your own helper does nothing. Most confusing behaviour in a first Gatling project comes from this split between build time and run time.

Each virtual user carries a Session, an immutable map of attributes that actions read and replace. Feeders push records into it from CSV, JSON or other sources, consumed with a queue, random, shuffle or circular strategy. Checks run on each response: they verify status codes, headers or body content, and extract values with JMESPath, JsonPath, CSS selectors or regular expressions, which saveAs stores for later requests. That is how correlation works: a token in the login response becomes "#{token}" in the next request. A failed check marks the request KO, and the user carries on unless the scenario uses exitHereIfFailed, exitBlockOnFail or tryMax. Without an explicit status check, Gatling applies an implicit one that accepts 2xx and 304 responses.

Every scenario is injected with either injectOpen or injectClosed, and the steps inside one call must all be the same kind. Open steps such as constantUsersPerSec and rampUsersPerSec control how many users arrive per second, regardless of how quickly the system answers, which is how most websites and public APIs behave. Closed steps such as constantConcurrentUsers hold the number of users in the system constant, which matches systems with a hard cap and a queue, such as a call centre or a ticketing site. Gatling’s documentation warns that a closed model applied to an open system is misleading: as response times rise, the injection slows to match the cap you set, so the test quietly applies less load exactly when the system struggles.

While a simulation runs, Gatling records each request’s outcome to a simulation.log file. When it ends, it builds a static HTML report from that log and evaluates the assertions declared in setUp. Assertions target global statistics, every request with forAll, or one request or group with details, and test response time metrics, request counts, failure percentages or requests per second. If any assertion fails, the simulation fails, and so does the Maven, Gradle or npm command that launched it. That exit status is what turns a load test into a pipeline gate. Logging is buffered, so a run that is killed forcibly can lose its last data points.

Keep the starter’s Maven layout: simulations in src/test/java, and data files, gatling.conf and logback-test.xml in src/test/resources. As soon as there is more than one journey, move each into its own class of reusable chains (login, search, checkout) and compose scenarios from them, so a change to the login flow is made once. Write one simulation class per test type, such as smoke, load and soak, and select it in CI with -Dgatling.simulationClass. Read everything that varies between runs, such as the base URL, arrival rate and duration, from system properties with Integer.getInteger or System.getProperty and a sensible default, so the same code runs against a laptop, staging and a pre-production environment without edits. In TypeScript projects, getParameter and getEnvironmentVariable do the same job, with values passed as key=value arguments to npx gatling run.

Realistic load needs distinct users and the values the server hands back. A feeder supplies one record per virtual user; the default queue strategy crashes the run when records run out, so use circular or random for long tests, or provide enough rows. Extract dynamic values with checks and saveAs, and reference them later as EL strings. Values that must differ per user belong in the Session or in EL functions such as randomUuid(), never in plain Java inside the builder. In Java, a check’s is method takes a value or a function; use isEL when the expected value is an EL string.

Decide first whether the system is open or closed. A public website or API is open: users arrive whether or not earlier ones have finished, so model arrival rates with injectOpen. Use injectClosed only when the real system caps concurrency, such as a worker pool fed from a queue. Ramp up rather than starting at full rate, so the report shows where response times bend. For a capacity search, incrementUsersPerSec builds a staircase of levels separated by ramps, and the response time against global throughput chart shows the level where latency climbs. Set maxDuration as a safety net, because a closed model only ends when users finish their scenarios. Several scenarios can run in one setUp, each with its own profile, which is how a realistic mix of browsing and buying is expressed.

Gatling needs nothing beyond Java in CI: check out, set up a JDK, run the Maven goal. GitHub Actions sets CI=true, and the Maven plugin then runs non-interactively and fails if more than one simulation is available, so always name the class. Run load tests on a schedule or on demand against a dedicated environment rather than on every push, since shared environments make results noisy and a load test can disrupt other people’s work. Upload target/gatling whether the job passes or fails: the report is the evidence for a failed assertion. Watch the runner itself, because a saturated generator inflates response times; if CPU is the limit, lower the rate per runner or move to bigger machines before trusting the numbers.

The JavaScript SDK mirrors the Java DSL closely, so the concepts above carry over. Projects follow the gatling-js-demo layout: simulations in src as files ending .gatling.ts or .gatling.js, with gatling.conf and data in resources. The CLI, installed as @gatling.io/cli, builds and runs them with npx gatling run --typescript --simulation followed by the file’s base name. Be clear about the runtime: the CLI downloads GraalVM and runs the bundle on its JavaScript engine inside a JVM, not on Node.js, so Node built-in modules such as fs are not available, and npm packages that depend on them will fail. GraphQL support is in the Java SDK only for now. Durations are numbers of seconds or objects with an amount and unit.

Start with the summary table, then the percentiles over time chart: a 99th percentile that climbs while the arrival rate is flat points at saturation, whereas a spike during the ramp often points at cold caches or connection setup. Percentile charts include successful requests only, so read them with the failure counts beside them. Name requests and groups deliberately, because those names are what the report, the forAll and details assertions, and any later comparison key on. Assert on percentiles and error rates rather than the maximum, which a single outlier decides. To compare runs over time with Community Edition you keep and compare the archived reports yourself; trends across runs, live dashboards and service level objectives are Enterprise features. Keep the environment, data volume and generator size the same between runs, or the comparison measures the setup rather than the code.