Performance Testing: JMeter, k6 & Gatling Vergleich [2026]

Was ist Performance Testing?

Eine Anwendung die funktioniert ist nicht automatisch eine Anwendung die performt. Performance Testing beantwortet drei Fragen: Wie schnell antwortet das System? Wie viele gleichzeitige Nutzer hält es aus? Wo bricht es?

Qualität ist kein Gate am Ende der Pipeline. Qualität ist die Pipeline. Performance Testing gehört nicht erst vor den Go-Live, sondern in jede Sprint-Iteration. Wer erst in der letzten Woche vor dem Release testet, findet Probleme die sich nicht mehr fixen lassen.

Die drei häufigsten Testarten:

• Lasttest: Erwartete Nutzerlast simulieren und Antwortzeiten messen. Ziel: SLAs validieren.
• Stresstest: System bewusst über die Grenze belasten. Ziel: Bruchpunkt finden bevor der Kunde ihn findet.
• Ausdauertest (Soak Test): Moderate Last über 8-24 Stunden. Ziel: Memory Leaks und Degradation erkennen die in kurzen Tests unsichtbar bleiben.

Die Tool-Auswahl hängt vom Team, der Sprache und der Pipeline ab. Hier der Vergleich der drei relevantesten Open-Source-Tools, ergänzt durch Qyteras eigenen QLoad-Service.

JMeter vs. k6 vs. Gatling im Vergleich

Apache JMeter

JMeter ist der Klassiker. Seit 1998 im Einsatz, GUI-basiert, riesige Community. Du kannst Lasttests erstellen ohne eine Zeile Code zu schreiben. Die GUI zeigt Testplan, Thread-Groups, Sampler und Listener als Baumstruktur.

Stärken:

• GUI für Test-Erstellung und Ergebnis-Analyse
• Breite Protokoll-Unterstützung: HTTP, JDBC, FTP, LDAP, SOAP, JMS
• Hunderte Plugins (JMeter Plugins Manager)
• 20+ Jahre Dokumentation, Stack Overflow, Tutorials

Schwächen:

• Hoher Ressourcenverbrauch: 1 Java-Thread pro simuliertem User. Bei 2.000 Usern wird JMeter selbst zum Bottleneck.
• XML-Testpläne (.jmx) sind schwer versionierbar und merge-unfähig in Git
• GUI-Tests lassen sich nicht im Code Review prüfen

# JMeter im CLI-Modus (für CI/CD)
jmeter -n 
  -t testplan.jmx           # Testplan (XML)
  -l results.jtl             # Ergebnisse loggen
  -e -o report/               # HTML-Report generieren

# Mit Parametern (z.B. Umgebung)
jmeter -n -t testplan.jmx 
  -Jhost=staging.example.com 
  -Jthreads=100 
  -Jduration=300

In einem Kundenprojekt war JMeter die richtige Wahl: Das QA-Team hatte keine Programmier-Erfahrung und konnte nach 2 Tagen Schulung eigenständig Lasttests erstellen. Als das gleiche Team später API-Lasttests in die CI/CD-Pipeline integrieren wollte, sind wir auf k6 umgestiegen. Methoden sind Werkzeuge, keine Religion.

Mehr zu JMeter: JMeter Tutorial

k6 (Grafana)

k6 ist das modernste Tool im Vergleich. Tests als JavaScript-Code, in Go kompiliert, extrem ressourceneffizient. Ein Laptop kann 10.000+ virtuelle User simulieren, wo JMeter bei 500 ins Schwitzen kommt.

Stärken:

• Tests als Code (JavaScript/TypeScript): versionierbar, reviewbar, mergebar
• Thresholds als Pass/Fail-Kriterien direkt im Test (p95 < 500ms, Fehlerrate < 1%)
• Grafana Cloud Integration für Dashboards und Alerting
• Minimal: eine Binärdatei, keine Java-Runtime, keine Dependencies

Schwächen:

• Keine GUI (Code-only). Nicht ideal für Teams ohne Programmier-Erfahrung.
• Kein JDBC/LDAP-Support (nur HTTP, WebSocket, gRPC)
• Browser-basierte Tests (k6 Browser) noch in Beta

// k6-lasttest.js — API-Lasttest mit Thresholds
import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "30s", target: 50 },   // Ramp-up auf 50 User
    { duration: "2m", target: 200 },   // Hochlast: 200 User
    { duration: "30s", target: 0 },    // Ramp-down
  ],
  thresholds: {
    http_req_duration: ["p(95)<500"],   // 95% unter 500ms
    http_req_failed: ["rate<0.01"],     // Fehlerrate unter 1%
  },
};

export default function () {
  const res = http.get("https://api.example.com/products");

  check(res, {
    "Status 200": (r) => r.status === 200,
    "Antwortzeit < 500ms": (r) => r.timings.duration < 500,
    "Body nicht leer": (r) => r.body.length > 0,
  });

  sleep(1); // Think Time: 1 Sekunde zwischen Requests
}

# k6 lokal ausführen
k6 run k6-lasttest.js

# Mit Grafana Cloud (Live-Dashboard)
k6 cloud k6-lasttest.js

# In GitHub Actions
# - uses: grafana/k6-action@v0.3.1
#   with:
#     filename: k6-lasttest.js

Ergebnisse beweisen, dass es funktioniert: In einem E-Commerce-Projekt haben wir mit k6 einen API-Engpass bei 150 gleichzeitigen Usern gefunden. Unter JMeter war der Engpass bei den gleichen 150 Usern nicht sichtbar, weil JMeter selbst 40% der CPU verbrauchte. k6 braucht für die gleiche Last weniger als 5% CPU.

Mehr zu k6: k6 Tutorial

Gatling

Gatling ist die Wahl für Java/Scala-Teams die Performance Tests als Code wollen. Die DSL ist ausdrucksstark, der HTML-Report der detaillierteste aller drei Tools, und die Architektur (Akka/Netty) skaliert besser als JMeter.

Stärken:

• Tests in Java, Scala oder Kotlin (passt in bestehende Maven/Gradle-Projekte)
• Gatling Recorder: Browser-Sessions aufzeichnen und als Code exportieren
• HTML-Reports mit Response-Time-Verteilung, Percentiles und Timeline
• Effiziente Architektur: 5.000-10.000 User pro Maschine

Schwächen:

• Scala-Syntax hat eine Lernkurve (Java DSL seit Gatling 3.9 als Alternative)
• Kleinere Community als JMeter oder k6
• Gatling Enterprise (Cloud) nur auf Anfrage

// Gatling Simulation (Java DSL, vereinfacht)
public class ApiLoadTest extends Simulation {

  HttpProtocolBuilder httpProtocol = http
    .baseUrl("https://api.example.com")
    .acceptHeader("application/json")
    .userAgentHeader("Gatling/LoadTest");

  ScenarioBuilder scenario = scenario("API Lasttest")
    .exec(http("GET Products")
      .get("/products")
      .check(status().is(200))
      .check(responseTimeInMillis().lt(500)))
    .pause(1)
    .exec(http("GET Product Detail")
      .get("/products/1")
      .check(jsonPath("$.name").exists()));

  { setUp(
    scenario.injectOpen(
      rampUsers(200).during(Duration.ofMinutes(2))
    )
  ).protocols(httpProtocol)
   .assertions(
     global().responseTime().percentile3().lt(500),
     global().failedRequests().percent().lt(1.0)
   );
  }
}

In einem Versicherungs-Projekt mit 500+ Microservices war Gatling die richtige Wahl: Das Team arbeitete ohnehin mit Maven und Scala. Die Performance Tests liefen als Teil des Build-Lifecycle. Jeder Merge Request triggerte automatisch einen Lasttest.

QLoad: Performance Testing as a Service

Nicht jedes Team will ein Performance-Testing-Framework selbst betreiben. QLoad ist Qyteras Performance Testing as a Service: Hochverfügbare, skalierbare Lasttests aus der Cloud, ohne eigene Infrastruktur.

Was QLoad bietet:

• Managed Infrastruktur: Lastgeneratoren in AWS, keine eigenen Server nötig
• Tool-agnostisch: JMeter, k6 oder Gatling, je nach Projekt
• Experten-Support: Qytera-Ingenieure designen und analysieren die Tests
• Ergebnis-Reports mit konkreten Handlungsempfehlungen

Open Source ist kein Kompromiss. Es ist ein Vorteil. QLoad kombiniert Open-Source-Tools mit Enterprise-Infrastruktur. Du behältst die Kontrolle über die Testskripte, wir kümmern uns um Skalierung und Analyse.

Cloud-Optionen im Überblick

Best Practices

1. Realistische Szenarien
   Nicht nur die Startseite testen. Nutzerflüsse nachbilden: Login, Suche, Warenkorb, Checkout. Daten aus Prod-Logs ableiten, nicht raten.
2. Thresholds als Quality Gate
   p95 < 500ms, Fehlerrate < 1%. Ohne Schwellwerte ist ein Lasttest nur eine Zahl. Mit Thresholds wird er ein automatisches Go/No-Go.
3. Performance Tests in CI/CD
   Qualität ist kein Gate am Ende der Pipeline. Qualität ist die Pipeline. Jeder Merge Request triggert einen Lasttest. Regression = Pipeline blockiert.
4. Isolierte Testumgebung
   Nie auf Prod testen (außer kontrollierte Canary-Tests). Staging mit produktionsnahen Datenmengen nutzen. Synthetische Testdaten verfälschen Ergebnisse.
5. Baseline + Vergleich
   Erste Messung als Baseline speichern. Bei jedem Release vergleichen. 10% Regression in der Antwortzeit ist ein Signal. 30% ist ein Blocker.
6. Ressourcen-Monitoring parallel
   Lasttest ohne Server-Monitoring ist blind. CPU, Memory, DB-Connections und Netzwerk gleichzeitig messen. Der Engpass ist selten dort wo du ihn vermutest.

Fazit

Tools wechseln. Qualitätsdenken bleibt. JMeter hat 20 Jahre gute Dienste geleistet und bleibt relevant für QA-Teams ohne Code-Erfahrung. k6 ist die Empfehlung für neue Projekte: Tests als Code, CI/CD-native, ressourceneffizient. Gatling für Java/Scala-Enterprise-Projekte mit Maven/Gradle-Buildkette.

Die wichtigste Erkenntnis aus hunderten Lasttest-Projekten: Das Tool ist nicht der Engpass. Die Teststrategie ist es. Wer keine realistischen Szenarien definiert, findet mit keinem Tool die richtigen Probleme.

Starte mit k6 wenn du ein neues Projekt hast. Bleibe bei JMeter wenn dein Team damit produktiv ist. Oder lass Qytera das Performance Testing übernehmen mit QLoad: die Tools, die Infrastruktur und die Expertise aus einer Hand.

FAQ: Häufig gestellte Fragen zu Performance Testing

Was ist der Unterschied zwischen Lasttest und Stresstest?

Lasttest simuliert die erwartete Nutzerlast und misst Antwortzeiten (SLA-Validierung). Stresstest überschreitet die Kapazität bewusst um den Bruchpunkt zu finden. Mehr dazu in unserem Lasttest-Konzept-Artikel.

Welches Tool für Anfänger?

JMeter: GUI-basiert, kein Code nötig. Für Entwickler: k6 mit JavaScript. Für Java-Teams: Gatling.

Wie viele virtuelle User brauche ich?

Analysiere deine Prod-Logs: Peak Concurrent Users × 1.5 als Ausgangswert für den Lasttest. Dann schrittweise erhöhen bis zum Bruchpunkt (Stresstest).

Kann ich Performance Tests in CI/CD integrieren?

Ja, alle drei Tools unterstützen CLI-Modus. k6 und JMeter haben offizielle GitHub Actions. Threshold-Verletzung blockiert die Pipeline automatisch.

JMeter oder k6?

k6 für neue Projekte (effizienter, Tests als Code, bessere CI/CD-Integration). JMeter wenn dein Team die GUI braucht oder du Nicht-HTTP-Protokolle testen musst (JDBC, LDAP, JMS).

Was kostet Performance Testing?

Alle drei Tools sind Open Source und kostenlos. Cloud-Services ab ~$99/Monat. QLoad von Qytera als Managed Service auf Anfrage.