Model the load before you measure it

Technology

Gatling is a JVM load generator with a typed DSL in Java, Kotlin, or Scala. Virtual users are messages on an asynchronous engine rather than threads, and every run writes an HTML report with the full response time distribution instead of an average and a shrug.

We name it alongside K6 in how we automate performance testing. Where K6 suits a JavaScript team keeping tests beside the app, Gatling suits a JVM codebase, a build that already runs Maven or Gradle, and a load profile you want to state precisely rather than approximate.

Monogram logo

Modeling

Where Gatling earns the JVM it runs on

  1. Open and closed workloads are different tests

    Gatling makes you choose. A closed injection profile holds concurrency fixed, which models a system sitting behind a pool. An open profile sets an arrival rate that does not slow down when your server does, which is what real traffic does. Pick the wrong one and you measure a bottleneck you do not have.

  2. A percentile report you can attach to a build

    Each run writes a self contained HTML report: the response time distribution, percentiles, throughput over time, errors grouped by cause. Assertions on those same statistics fail the run. A regression argument stops being somebody's memory of last month and becomes two artifacts you can put side by side.

  3. The JVM is the price of admission

    The open source tool drives load from one machine. Distributed injection and trend history across builds are the paid Enterprise product, so the free tier answers whether a change made things worse, not what happens at real peak. We reach for it alongside K6 rather than instead of it.