Генератор Gatling-симуляций
Создавайте Gatling Simulation.scala с профилями нагрузки, сценариями (repeat / during), HTTP-запросами с timeout, проверками и CSV-фидерами.
AK
appkiro.comGatling is an open-source load testing tool that simulates many users hitting your API or website at the same time, then reports response times, throughput, and errors. This generator turns the form below into a ready-to-run Simulation.scala file: configure the target URL, how users arrive, the requests they make, and the pass/fail checks — then download and run.
Who it's for
Backend / SRE / QA engineers who need real load numbers without writing Scala from scratch. Beginners and Gatling pros alike.
What you get
A complete Simulation.scala with HTTP protocol, scenarios, requests, checks, and an injection profile. Edit further if needed.
Privacy
Everything is generated in your browser. URLs, payloads, and credentials never leave this page.
exec(http(...)) call inside every scenario. Reorder, duplicate, or load a template.import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._
class GeneratedSimulation extends Simulation {
val httpProtocol = http
.baseUrl("https://example.com")
.acceptHeader("application/json")
.contentTypeHeader("application/json")
val scn1 = scenario("User Journey")
.repeat(1) {
exec(http("Home Page")
.get("/")
.requestTimeout(10.seconds)
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
.pause(1)
exec(http("Login")
.post("/api/auth/login")
.requestTimeout(10.seconds)
.body(StringBody("""{\"username\":\"${username}\",\"password\":\"${password}\"}"""))
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
.pause(1)
exec(http("Get Products")
.get("/api/products")
.requestTimeout(10.seconds)
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
.pause(1)
exec(http("Product Detail")
.get("/api/products/${id}")
.requestTimeout(10.seconds)
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
.pause(1)
exec(http("Add To Cart")
.post("/api/cart")
.requestTimeout(10.seconds)
.body(StringBody("""{\"productId\":\"${id}\",\"qty\":1}"""))
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
}
val scn2 = scenario("Browse Products")
.repeat(2) {
exec(http("Home Page")
.get("/")
.requestTimeout(10.seconds)
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
.pause(1)
exec(http("Login")
.post("/api/auth/login")
.requestTimeout(10.seconds)
.body(StringBody("""{\"username\":\"${username}\",\"password\":\"${password}\"}"""))
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
.pause(1)
exec(http("Get Products")
.get("/api/products")
.requestTimeout(10.seconds)
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
.pause(1)
exec(http("Product Detail")
.get("/api/products/${id}")
.requestTimeout(10.seconds)
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
.pause(1)
exec(http("Add To Cart")
.post("/api/cart")
.requestTimeout(10.seconds)
.body(StringBody("""{\"productId\":\"${id}\",\"qty\":1}"""))
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
}
val scn3 = scenario("Checkout Flow")
.repeat(1) {
exec(http("Home Page")
.get("/")
.requestTimeout(10.seconds)
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
.pause(1)
exec(http("Login")
.post("/api/auth/login")
.requestTimeout(10.seconds)
.body(StringBody("""{\"username\":\"${username}\",\"password\":\"${password}\"}"""))
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
.pause(1)
exec(http("Get Products")
.get("/api/products")
.requestTimeout(10.seconds)
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
.pause(1)
exec(http("Product Detail")
.get("/api/products/${id}")
.requestTimeout(10.seconds)
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
.pause(1)
exec(http("Add To Cart")
.post("/api/cart")
.requestTimeout(10.seconds)
.body(StringBody("""{\"productId\":\"${id}\",\"qty\":1}"""))
.check(status.is(200))
.check(responseTimeInMillis.lt(500))
.check(substring("success"))
)
}
setUp(
scn1.inject(
rampUsers(100).during(10.minutes),
constantUsersPerSec(100).during(20.minutes),
rampUsers(100).during(5.minutes)
),
scn2.inject(
rampUsers(100).during(10.minutes),
constantUsersPerSec(100).during(20.minutes),
rampUsers(100).during(5.minutes)
),
scn3.inject(
rampUsers(100).during(10.minutes),
constantUsersPerSec(100).during(20.minutes),
rampUsers(100).during(5.minutes)
)
).protocols(httpProtocol)
}
Gatling is an open-source tool that simulates many users hitting your website or API at the same time, then reports response times, throughput, and errors. Tests are written in a Scala DSL — short, readable, but unfamiliar if you have never seen it. This generator builds a complete Simulation.scala file from a friendly form: set a target URL, decide how users arrive, list the requests they make, add some pass/fail checks, and download a runnable file. You do not need to know Scala to start.
Pre-launch capacity check
Before a marketing push or product launch, simulate the expected concurrent users plus a safety margin. Confirm latency and error rate stay healthy under peak.
Stress test new endpoints
When shipping a new API, push it past expected traffic to find the breaking point and the failure mode (timeouts, 5xx, slow DB queries, OOM).
Regression in CI
Run a smoke-sized simulation on every release branch. Fail the pipeline if p95 latency or error rate crosses your SLO so regressions never reach production.
Capacity planning
Vary the user count across runs to chart latency vs. concurrency. Use the curve to size autoscaling, database connection pools, or CDN tiers.
Soak / endurance
Hold steady traffic for hours to surface memory leaks, slow connection drift, cache eviction storms, and other issues that hide in short tests.
Compare two implementations
Run the same simulation against two builds (current vs. candidate). Compare throughput and percentiles to make data-driven decisions on rewrites or library swaps.
repeat runs the request list N times. during runs for N seconds. forever runs until injection finishes.$${columnName} placeholders for feeder values.status.is(200),responseTimeInMillis.lt(500), substring("success"). src/test/resources/. results/.Gatling produces an HTML report under results/<run>/. Important numbers to look at:
status.is(200) alone misses a server that returns 200 with an error body.Gatling is an open-source load testing tool that simulates many users hitting your API or website at the same time. You write a small Scala file describing the user journey, run it from the command line, and Gatling produces an HTML report with response times, throughput (requests per second), error rates, and percentile graphs. Use it before launches, after big code changes, or whenever you need numbers (not guesses) about whether your service holds up under traffic.
You get a complete, runnable Simulation.scala file without learning the DSL first. Pick the target URL, the user injection shape, the requests, and click download. Then install Gatling once, drop the file into the project folder, and run ./gatling.sh. The HTML report tells you how the service behaves under the load you described.
Users = the peak number of virtual users (VUs) running concurrently. Ramp-up = the time taken to reach that peak (so traffic grows gradually instead of all at once). Hold = how long to sustain the peak load (the steady-state phase that produces the most useful numbers). Ramp-down = the time to wind users back to zero. Together they form a trapezoid shape similar to real production traffic.
A scenario is one user journey — a sequence of requests that one virtual user runs. You can have multiple scenarios in one simulation: e.g. one for browsers, one for buyers, one for admins. Each scenario can repeat its requests N times, run for N seconds, or run forever until injection finishes.
Checks decide whether each response is a pass or a fail. Common checks: status.is(200), responseTimeInMillis.lt(500), substring("success"). Failed checks count as KO requests in the report — without them, Gatling only knows whether the request returned at all, not whether the response was correct.
A feeder pulls parameterized data (login pairs, search terms, product ids) from a CSV/JSON file and injects it into your requests. Use ${columnName} in the URL, headers, or body and Gatling substitutes the value at runtime. Sharing modes: queue (one row per VU), random (sample with replacement), shuffle (shuffle once at start), circular (loop forever).
No. The generator builds the file in your browser. No data leaves the page. You install the Gatling CLI locally and run the simulation yourself.
Install Gatling (Homebrew, choco, or download the bundle from gatling.io). Save the downloaded .scala into src/test/scala/my/gatling/. Run ./gatling.sh -s my.gatling.GeneratedSimulation. The Setup & run tab shows the exact commands per OS.
Yes. The output is plain Gatling DSL. Edit anything after download — add custom assertions, chained scenarios with shared session variables, dynamic pacing, group blocks, or response capture (.check(jsonPath("$.id").saveAs("id"))). The generator handles the common 80% so you do not start from a blank file.
Gatling is great for HTTP load tests on the JVM with beautiful reports, especially in CI pipelines. k6 (JavaScript) is friendlier for developers who avoid the JVM. JMeter has the broadest plugin ecosystem but a heavier UI. For Spring/Java/Kotlin teams that already use the JVM, Gatling is usually the path of least friction.