Gatling-Lasttests: das JVM-Tool im Überblick

Gatling ist ein kostenloses Lasttest-Tool unter Apache-2.0-Lizenz, in dem jeder Test eine als Code geschriebene Simulation ist, die auf der JVM läuft und nach jedem Lauf einen HTML-Bericht liefert. Ein Gatling-Lasttest passt zu Entwicklerteams, die Tests im Repository, offene oder geschlossene Lastmodelle und Assertions wollen, die den Build scheitern lassen. Wer einen grafischen Test-Builder oder viele Protokolle braucht, ist mit JMeter besser bedient, und wer ein einzelnes Binary ohne JVM möchte, mit k6.

Wir haben Gatling für dieses Review nicht selbst ausgeführt. Die Fakten stammen aus der Dokumentation, dem Repository und den Release-Seiten von Gatling, geprüft am 9. Oktober 2026; die Einschätzungen sind unsere eigenen.

Wer entwickelt Gatling, und wird es noch gepflegt?

Gatling Corp, ein französisches Unternehmen, entwickelt Gatling und hält das Urheberrecht daran. Das Projekt wird aktiv gepflegt: 2026 sind bisher drei JVM-Versionen erschienen.

Die Lizenzseite weist Gatling Corp das Urheberrecht zu. Maven Central führt 3.15.0 im Februar, 3.15.1 im Mai und 3.16.0 am 29. September 2026, und das JavaScript-SDK erreichte am 6. Oktober Version 3.16.1. Die Release Notes zu 3.16 bringen GraphQL und gemeinsame Queues zwischen virtuellen Benutzern. Das README nennt das Repository die Community Edition, frei nutzbar auch für kommerzielle Zwecke (geprüft am 9. Oktober 2026).

Was brauchen Sie, um Gatling auszuführen?

Eine 64-Bit-JVM für Java, Kotlin oder Scala, oder Node.js für JavaScript und TypeScript. In beiden Fällen läuft die Simulation selbst auf einer JVM.

Die Installationsseite unterstützt OpenJDK-LTS-Versionen von 11 bis 25 und schließt 32-Bit-JVMs und OpenJ9 aus. Die JavaScript-CLI setzt Node.js 24 oder neuer voraus und lädt ein Gatling-Runtime-Bundle herunter, laut README von gatling-js samt GraalVM (geprüft am 9. Oktober 2026).

Wie ist eine Gatling-Simulation aufgebaut?

Eine Simulation definiert Szenarien, gibt jedem ein Injektionsprofil und hängt eine Protokollkonfiguration an; registriert wird alles in einem einzigen setUp-Aufruf.

In der Simulationsreferenz verkettet ein Szenario Anfragen mit Pausen, Schleifen und Bedingungen. Diese Java-Simulation speichert eine Produkt-ID aus einer Suche, pausiert eine bis drei Sekunden und öffnet das Produkt, während die Ankünfte auf 20 Benutzer pro Sekunde steigen und zehn Minuten lang gehalten werden:

public class ShopSimulation extends Simulation {

  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder shoppers = scenario("Shoppers")
      .exec(http("search").get("/api/products?q=lamp")
          .check(jsonPath("$[0].id").saveAs("id")))
      .pause(1, 3)
      .exec(http("product").get("/api/products/#{id}"));

  {
    setUp(shoppers.injectOpen(
        rampUsersPerSec(1).to(20).during(120),
        constantUsersPerSec(20).during(600)))
      .protocols(api)
      .assertions(
          global().responseTime().percentile(95.0).lt(800));
  }
}

Die Imports sind weggelassen, und #{id} liest über Gatlings Expression Language den gespeicherten Wert. Gatling vs k6 zeigt eine Simulation in JavaScript.

Sollten Sie Benutzer offen oder geschlossen injizieren?

Offen, für die meisten Websites und APIs, bei denen neue Benutzer weiter eintreffen, egal wie langsam das System wird. Geschlossen passt zu Systemen, die die Parallelität begrenzen, etwa einer Ticket-Warteschlange.

Die Referenz zu Injektionsprofilen trennt die API: injectOpen nimmt Ankunftsraten wie rampUsersPerSec, injectClosed Parallelitätsziele wie constantConcurrentUsers. Die Seite zu Lastmodellen sagt, dass sich die meisten Websites als offene Systeme verhalten und ein Profil die beiden nicht mischen kann (geprüft am 9. Oktober 2026). Unser Beitrag zum offenen vs geschlossenen Lastmodell erklärt die Wahl.

Wie funktionieren Checks, Assertions und der Bericht?

Checks prüfen jede Antwort und können Werte daraus speichern, Assertions bewerten den ganzen Lauf, sobald er endet. Danach schreibt jeder Lauf einen HTML-Bericht.

Ohne expliziten Status-Check prüft Gatling, ob jede HTTP-Antwort 2XX oder 304 ist. Assertions prüfen Antwortzeiten, Anfragezahlen oder Anfragen pro Sekunde, global oder pro Anfrage, und eine einzige gescheiterte Assertion lässt die Simulation scheitern. Der HTML-Bericht zeigt Antwortzeitbereiche und Perzentile, gestartete Benutzer pro Sekunde, gleichzeitige Benutzer und Anfragen pro Sekunde; seine Perzentile im Zeitverlauf zählen nur erfolgreiche Anfragen (geprüft am 9. Oktober 2026).

Wie passt Gatling in Build und CI?

Über das Plugin für Maven, Gradle, sbt oder npm, das in jedem CI-System läuft. Eine gescheiterte Assertion lässt den Build scheitern.

Das Maven-Plugin bindet gatling:test an die Phase integration-test, sodass mvn verify es ausführt, und mit CI=true entfällt die Abfrage der Simulation (der Lauf scheitert dann, wenn das Projekt mehr als eine Simulation enthält und keine benannt ist). Das Gradle-Plugin nutzt gatlingRun, und das sbt-Plugin nimmt nur Scala-Simulationen an. Die fertigen CI-Integrationen von Gatling, etwa die GitHub Action, starten Läufe in Gatling Enterprise (geprüft am 9. Oktober 2026). Unser Leitfaden zu GitHub Actions zeigt den Workflow dazu.

Welche Protokolle unterstützt Gatling?

HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events und JMS sind ohne Grenzen dabei. gRPC, MQTT und GraphQL sind separate Plugins, die außerhalb von Gatling Enterprise auf 5 Benutzer und 5 Minuten begrenzt sind.

Das README stellt die ersten fünf unter Apache 2.0. Die Setup-Seiten für gRPC, MQTT und GraphQL stellen jedes Plugin unter die Gatling Enterprise Component License: unbegrenzt in Gatling Enterprise, während ein Test mit der Community Edition bei 5 Benutzern oder 5 Minuten stoppt. Diese Lizenz erlaubt die kostenlose Nutzung für höchstens ein Jahr, nur für interne Tests der eigenen Webanwendungen; sie endet, sobald ein Limit erreicht ist, und Gatling kann die Limits ändern. GraphQL setzt 3.16.0 oder neuer voraus. Laut Release Notes und README unterstützt das JavaScript-SDK GraphQL noch nicht, obwohl die Setup-Seite bereits ein npm-Paket nennt; prüfen Sie das also, bevor Sie einen GraphQL-Test in JavaScript planen (geprüft am 9. Oktober 2026). Unser Leitfaden zum Lasttest einer GraphQL-API umgeht die Grenze mit einfachen HTTP-Anfragen.

Was bringt Gatling Enterprise zusätzlich?

Gatling Enterprise ist die kommerzielle Edition auf derselben Engine. Sie erzeugt Last aus verwalteter oder privater Infrastruktur, was die freie Edition nicht tut.

Laut README führt Enterprise Tests auf verwalteten Lastgeneratoren oder in Ihren eigenen Konten bei AWS, Azure, GCP oder Kubernetes aus und ergänzt Live-Dashboards, Trends, Teams mit SSO und CI/CD-Integrationen. Die FAQ sagt, dass die Community Edition keine verteilten Tests unterstützt und dass Simulationen unverändert zu Enterprise wechseln können (geprüft am 9. Oktober 2026).

LoadFocus, der Herausgeber dieser Website, führt keine Gatling-Simulationen aus. LoadFocus führt JMeter-Testpläne und k6-Skripte aus, und zwar aus 25 Cloud-Regionen. Für Gatling führt der Weg zu mehr Maschinen also über Gatling Enterprise.

Was kann Gatling gut, und wo liegen seine Grenzen?

Stark ist Gatling bei Tests als Code, den man im Review prüfen kann, bei Lastmodellen und bei Berichten ohne Einrichtung. Schwächer ist es bei Protokollen jenseits von Web und Messaging und bei kostenloser Skalierung über eine Maschine hinaus.

Das README hebt die Engine hervor: nicht blockierend, auf Netty gebaut, jeder virtuelle Benutzer eine leichtgewichtige Nachricht. Grenzen, die die Dokumentation selbst nennt (geprüft am 9. Oktober 2026):

• Gatling ist kein Browser: Laut der Seite zum HTTP-Protokoll führt es kein JavaScript aus.
• Das JavaScript-SDK kennt kein JMS und kann keine npm-Bibliotheken nutzen, die native Binaries oder Node.js-APIs brauchen.
• HTTP-Caching ist standardmäßig aktiv, was die Zahl der Anfragen senken kann.
• Das Format von simulation.log ist nicht dokumentiert und kann sich jederzeit ändern.

Wann sollten Sie stattdessen k6, JMeter oder Locust wählen?

Wählen Sie ein anderes Tool, wenn dessen Sprache, Protokolle oder kostenloser Weg zur Skalierung besser zu Ihrem Team passen.

Unser Überblick über Open-Source-Lasttest-Tools stellt Gatling neben fünf weitere.

Wählen Sie stattdessen k6, wenn Sie in der CI ein einzelnes Binary ohne JVM, Thresholds, die einen scheiternden Lauf früh stoppen können, oder gRPC als eingebautes Protokoll wollen (geprüft am 9. Oktober 2026). Gatling vs k6 vergleicht die beiden.

Wählen Sie stattdessen JMeter, wenn Ihre Tester Tests in einer GUI bauen oder Sie JDBC, LDAP oder FTP aus dem Kern brauchen (geprüft am 9. Oktober 2026). LoadFocus führt vorhandene JMeter-Testpläne aus, aus 25 Cloud-Regionen, und Gatling vs JMeter geht tiefer.

Wählen Sie stattdessen Locust, wenn Ihr Team Python schreibt und einen verteilten Modus im kostenlosen Tool möchte (geprüft am 9. Oktober 2026). Unser Locust-Review beschreibt es.

FAQ

Darf man Gatling kostenlos kommerziell nutzen? Ja. Die Community Edition steht unter Apache 2.0. Die Plugins für gRPC, MQTT und GraphQL haben eine eigene Lizenz und sind außerhalb von Gatling Enterprise auf 5 Benutzer und 5 Minuten begrenzt.

Braucht man Java, um Gatling zu nutzen? Für Java, Kotlin oder Scala ja: ein 64-Bit-OpenJDK-LTS von 11 bis 25. Das JavaScript-SDK braucht Node.js 24 oder neuer, und seine CLI lädt die JVM-Laufzeit selbst herunter.

Kann LoadFocus Gatling-Tests ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte aus. Um eine Gatling-Simulation auf mehrere Maschinen zu verteilen, nutzen Sie Gatling Enterprise.

Weiterlesen

• Gatling vs JMeter: Tests als Code oder GUI-Testplan?
• Gatling vs k6: JVM-Simulationen oder ein Go-Binary?
• Open-Source-Lasttest-Tools: sechs Optionen im Überblick
• Gatling vs Locust: JVM-Simulationen oder Python-Locustfiles?
• NBomber-Lasttests: das .NET-Framework im Überblick

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.