Gatling

nothingFor admits nobody and shifts the rest of the profile later. atOnceUsers starts a fixed count at one instant. rampUsers spreads a fixed count evenly over a window. stressPeakUsers spreads the same count bunched around that window's middle.

Chain closed injection steps in one call: constantConcurrentUsers(300) for ten minutes, then rampConcurrentUsers(300).to(50) over a wind-down window, then constantConcurrentUsers(50) if that level must be held. Java, Kotlin, JavaScript and TypeScript register them with injectClosed; Scala uses inject.

Both declare an arrival rate in users per second, not a headcount. constantUsersPerSec(20).during(15) starts 300 users, 20 every second. rampUsersPerSec(10).to(20).during(10) climbs linearly from 10 to 20 a second, starting 150.

setUp registers this simulation's populations, each one a scenario welded to an injection profile, and returns a handle for run-wide settings such as protocols and maxDuration. It must be called exactly once, from the Simulation's constructor.

Gatling has one staircase builder per workload model: incrementUsersPerSec(rateIncrement) and incrementConcurrentUsers(usersIncrement). Both chain .times(levels).eachLevelLasting(duration), plus optional .separatedByRampsLasting(duration) and .startingFrom(x).

Store each flow in a chain value returned by a standalone exec call, then hand both to scenario("Shopper").exec(browse, checkout). Chains are ordinary values, so one scenario composes as many of them as you like, in order.

repeat(n) runs the wrapped chain n times; during(d) runs it until d has elapsed. Java, Kotlin and JavaScript attach the body with .on(...), while Scala passes it in a second parameter list.

A Gatling simulation in Java or Kotlin extends io.gatling.javaapi.core.Simulation and needs two imports per DSL family: the package wildcard for the types, plus a static import of CoreDsl and HttpDsl for the DSL methods.

Three: @gatling.io/core for the DSL and the simulation function, @gatling.io/http for the HTTP protocol builder, and @gatling.io/cli, a dev dependency that supplies the gatling command you invoke as npx gatling.

pause(10) waits a fixed ten seconds: a bare number means seconds in every Gatling SDK. pause(1, 4) draws a fresh duration uniformly at random between one and four seconds each time a virtual user reaches that step.

A Gatling check is an ordered chain of six steps: pick a check type, extract an occurrence, transform it, validate it, name it, save it. Only two are supplied when omitted: an implicit find() and an implicit exists().

Gatling interpolates only the #{attributeName} placeholder. The older ${...} form was removed in Gatling 3.11.0 and is no longer interpreted, so a URL containing it is sent to the server as literal characters.

Gatling ships csv, tsv, ssv and separatedValues for delimited files, plus jsonFile, jsonUrl and sitemap. The path is resolved from your classpath root: src/main/resources or src/test/resources on the JVM, resources in the JavaScript SDK.

Gatling feeders take exactly four strategies: queue, random, shuffle and circular. Queue is the default. Queue and shuffle hand out each record once and stop the run when the stock empties; random and circular reuse records and never run out.

Attach a check to the first request: jsonPath("$.orderId").saveAs("orderId"), then read it back with the placeholder #{orderId} in the next request's URL or body. If the id is missing, the implicit exists() fails, nothing is saved, and both requests are KO.

You register them with assertions(...) on the setUp call, in the Simulation constructor. Each assertion chains a scope, then a statistic, then a metric, then a condition - for example details("Checkout").responseTime().percentile(95.0).lt(800).

Gatling's index.html shows response-time ranges, a simulation card, an assertions table, the Stats table, an errors table, users start rate, concurrent users, response-time distribution, percentiles over time over successful requests only, requests per second and responses per second.

A failed assertion exits 2. Gatling declares exactly three status codes: 0 for success, 1 for invalid command-line arguments, and 2 for assertions failed. Other load generators differ; k6 exits 99 on a breached threshold.

A Gatling simulation that registers no assertions gives Gatling nothing to judge. It folds an empty list of assertion results into a single true and returns Success, exit code 0 — the same integer a genuinely passing run returns.

That chart plots successful requests only, so timeouts and early failures never enter it. Read the % KO column, the Stats table's response-time columns, the failed bar of Response Time Ranges and the Errors table instead.

Maven runs mvn gatling:test, Gradle runs ./gradlew gatlingRun, sbt runs sbt Gatling/testOnly with a class pattern, and the JavaScript CLI runs npx gatling run. Each build tool names its own entry point; there is no shared Gatling command.

Four times the declared load. Each machine runs the whole profile independently, and Gatling's Community Edition merges nothing, so you get four results directories, four HTML reports and four separate assertion verdicts.

Force the class. Pass -Dgatling.simulationClass=com.project.simu.CheckoutSimulation on the mvn command line, or set a simulationClass element in the plugin configuration. Under CI the goal deliberately refuses to guess when several simulations exist.

A Gatling load profile is a chain of injection step builders written in the simulation's own source and handed to a single setUp call. There is no thread pool to size, because Gatling's engine is asynchronous and does not allocate one operating-system thread per virtual user.

Yes. Assertions declared on setUp are all evaluated after the simulation has finished; if at least one fails the simulation fails and the process exits 2. A run that declares no assertions exits 0, because it judged nothing.