Gatling vs Locust: JVM-Simulationen oder Python-Locustfiles?

Gatling und Locust sind beide kostenlose Open-Source-Tools, die Lasttests als Code in Ihrem Repository halten. Nehmen Sie Gatling, wenn Ihr Team auf der JVM arbeitet oder Sie offene und geschlossene Injektionsprofile, Assertions und einen HTML-Bericht in einem Paket wollen. Nehmen Sie Locust, wenn Ihr Team Python schreibt, eine Web-Oberfläche zum Starten und Beobachten eines Laufs schätzt und den verteilten Modus ohne kommerzielle Edition braucht.

Die Fakten in diesem Vergleich Gatling vs Locust stammen aus der Dokumentation und den Repositories der beiden Projekte, geprüft am 13. Oktober 2026.

Was ist der Unterschied zwischen Gatling und Locust?

Gatling führt Simulationen auf der JVM aus, Locust führt gewöhnliche Python-Programme aus. Gatling bringt ein Lastmodell und einen Bericht von Haus aus mit, bei Locust schreiben Sie die Testlogik selbst.

Die README von Gatling beschreibt eine nicht blockierende Engine auf Basis von Netty und ein SDK in fünf Sprachen: Java, Kotlin und Scala laufen über Maven, Gradle oder sbt, JavaScript und TypeScript über ein eigenes SDK. Die Installationsseite verlangt ein 64-Bit-OpenJDK-LTS von 11 bis 25 und für das JavaScript-SDK Node.js 24 oder neuer.

Die README von Locust nennt es eine Möglichkeit, skalierbare Lasttests in reinem Python zu schreiben, und die Paketmetadaten verlangen Python 3.11 oder neuer. Die Seite What is Locust sagt, Locust sei ereignisbasiert auf gevent, sodass ein Prozess viele tausend gleichzeitige Benutzer bewältigen kann (geprüft am 13. Oktober 2026).

Wie schreibt man denselben Test in beiden Tools?

In Gatling verketten Sie Anfragen zu einem Szenario und geben ihm ein Injektionsprofil. In Locust schreiben Sie eine Benutzerklasse mit Tasks und einer Wartezeit dazwischen.

Fünfzig gleichzeitige Benutzer rufen die Benutzerliste ab und pausieren danach ein bis drei Sekunden, fünf Minuten lang. In Gatlings Java-SDK (Imports weggelassen):

public class ApiSimulation extends Simulation {
  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder users = scenario("API users")
      .exec(http("list users").get("/api/users"))
      .pause(1, 3);

  {
    setUp(users.injectClosed(
        constantConcurrentUsers(50).during(300)))
      .protocols(api);
  }
}

Derselbe Test in Locust:

from locust import HttpUser, task, between


class ApiUser(HttpUser):
    wait_time = between(1, 3)

    @task
    def list_users(self):
        self.client.get("/api/users")

Die Referenz zur Injektion von Gatling nennt constantConcurrentUsers unter den Schritten des geschlossenen Modells. Locust bekommt Benutzerzahl und Laufzeit als Flags (geprüft am 13. Oktober 2026):

locust -f locustfile.py --headless -u 50 -r 5 -t 5m \
  --host https://staging.example.com

Wie modellieren Gatling und Locust die Last?

Gatling bietet offene und geschlossene Modelle, je nachdem, welche Methode Sie aufrufen. Locust arbeitet mit einem Pool von Benutzern und damit mit einem geschlossenen Modell.

Die Seite zu Lastmodellen von Gatling definiert geschlossene Systeme als solche mit begrenzter Zahl gleichzeitiger Benutzer und offene Systeme als solche, in denen Benutzer weiter eintreffen, egal wie langsam die Anwendung antwortet. Die meisten Websites seien offen. injectOpen nimmt Ankunftsraten, injectClosed nimmt Zielwerte für die Gleichzeitigkeit.

Im Locustfile-Leitfaden steht, dass die Wartezeit den Durchsatz nur begrenzen kann und keine neuen Benutzer startet, um eine Zielrate zu erreichen. Dauert ein Durchlauf länger als die Wartezeit erlaubt, fällt die Rate unter den Zielwert (geprüft am 13. Oktober 2026). Warum das wichtig ist, erklärt unser Leitfaden zum offenen vs geschlossenen Lastmodell.

Wie führt man einen Test aus, der größer ist als eine Maschine erzeugen kann?

Locust bringt den verteilten Modus mit. Die Open-Source-Edition von Gatling erzeugt Last von einer Maschine, verteilte Läufe brauchen Gatling Enterprise.

Locust startet einen Prozess mit --master und beliebig viele Prozesse mit --worker. Laut den Docs zur verteilten Last nutzt ein Python-Prozess nicht mehr als einen Kern, daher läuft ein Worker pro Kern, und --processes startet mehrere auf einer Maschine. Ein Kubernetes-Operator verwaltet verteilte Läufe in einem Cluster.

Die FAQ von Gatling sagt, die Community Edition unterstütze keine verteilten Tests, und die README beschreibt Enterprise als Betrieb auf verwalteten Lastgeneratoren oder privater Infrastruktur (geprüft am 13. Oktober 2026).

Es gibt einen Ausweg aus beiden. LoadFocus, der Herausgeber dieser Website, führt weder Gatling-Simulationen noch Locust-Tests aus. Wer keines von beiden im großen Maßstab betreiben möchte, kann dort k6-Skripte und JMeter-Testpläne aus 25 Cloud-Regionen laufen lassen. Der k6-Validator von LoadFocus warnt, dass Arrival-Rate-Szenarien dort mit einer festen Zahl von Benutzern laufen und deshalb keine Anfragerate halten. Der Umstieg von einem der beiden Tools bedeutet, den Test neu zu schreiben.

Wie entscheiden sie, ob ein Test bestanden ist, und welche Berichte gibt es?

Gatling wertet Assertions nach dem Lauf aus und schreibt jedes Mal einen HTML-Bericht. Locust beendet sich mit Exit-Code 1, wenn eine Anfrage fehlgeschlagen ist, und weitere Prüfungen ergänzen Sie als Listener.

Assertions in Gatling werden nach der Simulation ausgewertet, und eine einzige fehlgeschlagene Assertion lässt die Simulation scheitern. Der HTML-Bericht zeigt Perzentile der Antwortzeit, gestartete Benutzer pro Sekunde, gleichzeitige Benutzer und Anfragen pro Sekunde.

Laut den Headless-Docs von Locust endet der Lauf mit Exit-Code 1, wenn eine Stichprobe fehlgeschlagen ist, und ein Listener-Beispiel lässt den Lauf an Fehlerquote, durchschnittlicher Antwortzeit oder 95. Perzentil scheitern. Die Konfigurationsreferenz nennt --csv für Statistikdateien und --html für einen Bericht (geprüft am 13. Oktober 2026).

Welche Protokolle kann jedes Tool testen?

Gatling liefert mehr Protokolle mit, bei den neueren mit Grenzen. Locust liefert HTTP und HTTPS und erwartet für den Rest einen Python-Client.

Die README von Gatling führt HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events und JMS unter Apache 2.0 ohne Limits auf. gRPC, MQTT und GraphQL fallen unter die Gatling Enterprise Component License, und Tests damit sind in der Community Edition auf 5 gleichzeitige Benutzer und 5 Minuten begrenzt.

Die Seite zu anderen Systemen von Locust zeigt, wie man eine Protokollbibliothek einhüllt und jeden Aufruf meldet, mit Beispielen für gRPC und MQTT. Die Bibliothek muss mit gevent funktionieren, das I/O in kompiliertem C-Code nicht patchen kann, und locust-plugins ergänzt Benutzer für Kafka, Selenium und Playwright (geprüft am 13. Oktober 2026).

Welches Tool sollten Sie wählen?

Wählen Sie nach Sprache und danach, wie Sie das System belasten. Gatling passt zu JVM-Teams und Tests im offenen Modell, Locust zu Python-Teams und Tests mit eigener Logik.

Wählen Sie Gatling statt Locust, wenn Ihr Team auf der JVM zu Hause ist und Tests in Java, Kotlin oder Scala mit Maven, Gradle oder sbt bauen will, wenn Sie ein offenes Modell wie eine feste Ankunftsrate brauchen, wenn Sie JMS oder Server-Sent Events benötigen oder wenn Sie Assertions und einen Bericht ohne zusätzlichen Code wollen.

Wählen Sie Locust statt Gatling, wenn Ihr Team Python schreibt und Tests einen internen Python-Client wiederverwenden sollen, wenn Sie eine Web-Oberfläche wollen, um einen Lauf zu starten und die Last währenddessen zu ändern, wenn Sie den verteilten Modus im kostenlosen Tool brauchen oder wenn das System überwiegend wartende Benutzer sieht und es für Ihr Protokoll eine gevent-taugliche Python-Bibliothek gibt.

Für einen GUI-Testbuilder lohnt ein Blick auf JMeter, für ein einzelnes Binary ohne JVM oder Python auf k6.

FAQ

Ist Gatling schneller als Locust? Das haben wir nicht selbst gemessen, deshalb nennen wir keinen Sieger. Fair vergleichen lässt sich das nur mit demselben Szenario in beiden Tools auf Ihrer eigenen Hardware.

Kann Locust Gatling-Simulationen ausführen? Nicht laut der Dokumentation von Locust, die Tests nur als Python-Code beschreibt. Eine Gatling-Simulation muss als Locustfile neu geschrieben werden, und umgekehrt gilt dasselbe.

Kann LoadFocus Gatling- oder Locust-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, bei Locust den Master-Worker-Modus oder den Kubernetes-Operator.

Weiterlesen

• Gatling-Lasttests: das JVM-Tool im Überblick
• Locust-Lasttests: das Python-Tool im Überblick
• Gatling vs k6: JVM-Simulationen oder ein Go-Binary?
• Locust vs JMeter: Python-Skripte oder JMeter-Testpläne?
• Offenes vs geschlossenes Lastmodell: welches passt wann?

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