JMeter Tutorial: Performance Testing Schritt für Schritt

Du sollst eine Webanwendung lasttesten und niemand im Team hat Performance-Testing-Erfahrung? Dann ist Apache JMeter dein Einstieg. Das Tool ist kostenlos, läuft auf jedem Java-fähigen Rechner und du brauchst keine Programmierkenntnisse für die ersten Tests.

In diesem Tutorial baust du Schritt für Schritt deinen ersten JMeter-Lasttest. Du lernst Installation, Test-Plan-Aufbau, HTTP-Requests, Ergebnisauswertung. Und ich zeige dir, wie du JMeter in eine CI/CD-Pipeline einbaust statt nur im GUI zu klicken. Am Ende vergleiche ich JMeter mit k6, Gatling und Locust, damit du weißt, wann du wechseln solltest.

Aktuelle stabile Version: Apache JMeter 5.6.3 (Quelle: jmeter.apache.org/changes). Empfohlene Java-Version: Java 17 oder neuer (Java 8 reicht zum Starten, aber Heap-Management ist mit modernem JDK deutlich besser).

Was ist Apache JMeter?

Apache JMeter ist ein Open-Source-Lasttest-Werkzeug der Apache Software Foundation, geschrieben in Java. Es simuliert hunderte oder tausende virtuelle Nutzer und misst, wie ein System unter Last reagiert: Antwortzeiten, Durchsatz, Fehlerraten. Ursprünglich für Web-Anwendungen gedacht, kann JMeter heute auch APIs (REST/SOAP), Datenbanken (JDBC), Message Queues (JMS, Kafka) und FTP-Server testen.

JMeter arbeitet nach dem Master-Worker-Prinzip: Du baust einen Test-Plan mit Thread Groups (virtuelle Nutzer), Samplern (Requests), Logic Controllern (Reihenfolge) und Listenern (Ergebnis-Sammler). Das Ergebnis ist eine .jmx-Datei in reinem XML, die du versionierst, im Team teilst und in der Pipeline ausführst.

JMeter konkurriert mit modernen Tools wie k6 (Code-first) und Gatling (Scala-DSL). Für eine vollständige Tool-Übersicht inklusive Open-Source- und Commercial-Optionen siehe unsere Performance-Testing-Tools-2026-Übersicht. Wenn du das Konzept hinter Performancetests verstehen willst (Lasttest vs. Stresstest vs. Endurance), starte beim Performance-Testing-Pillar.

JMeter installieren (macOS, Windows, Linux, Docker)

JMeter braucht ein Java Runtime Environment (JRE) ab Version 8, empfohlen Java 17 (LTS). Prüfe das erst:

java -version
# erwarte: openjdk version "17.x.x" oder neuer

Wenn Java fehlt: macOS via brew install openjdk@17, Ubuntu via sudo apt install openjdk-17-jdk, Windows via Adoptium (adoptium.net).

JMeter herunterladen auf jmeter.apache.org/download_jmeter.cgi. Hol dir das Binary apache-jmeter-5.6.3.tgz für Linux/macOS oder .zip für Windows.

# macOS / Linux
curl -O https://dlcdn.apache.org/jmeter/binaries/apache-jmeter-5.6.3.tgz
tar -xzf apache-jmeter-5.6.3.tgz
cd apache-jmeter-5.6.3
bin/jmeter   # startet die GUI

Schneller Weg über Docker (keine lokale Java-Installation nötig):

docker run --rm -v $(pwd):/tests \
  justb4/jmeter:5.5 \
  -n -t /tests/plan.jmx -l /tests/results.jtl

Mit Docker bleibst du unabhängig vom lokalen Java-Setup. Das ist nützlich, wenn dein Team unterschiedliche Betriebssysteme nutzt. Und es zahlt sich aus, wenn JMeter später in einer Pipeline laufen soll (siehe Abschnitt CI/CD).

Test-Plan und Thread Group erstellen

Starte JMeter via bin/jmeter. Du siehst einen leeren Test-Plan in der Sidebar. Rechtsklick auf Test Plan → Add → Threads (Users) → Thread Group.

Die Thread Group definiert deine virtuellen Nutzer. Drei Werte sind wichtig:

• Number of Threads (users): Anzahl der gleichzeitigen Nutzer. Für den ersten Test 10 reichen.
• Ramp-up period (seconds): Zeit, in der alle Threads gestartet werden. Bei 10 Threads und 10 Sekunden startet jede Sekunde ein neuer Thread.
• Loop Count: Wie oft jeder Thread den Test durchläuft. Für eine erste Messung 5.

Setze die Werte auf 10 / 10 / 5. Das ergibt 50 Requests insgesamt, verteilt über mindestens 10 Sekunden. Genug, um zu sehen, ob das System überhaupt reagiert, und wenig genug, um den Server nicht versehentlich umzuwerfen.

HTTP-Request konfigurieren

Rechtsklick auf Thread Group → Add → Sampler → HTTP Request. Fülle die Felder:

• Protocol: https
• Server Name or IP: jsonplaceholder.typicode.com (kostenloser Test-Endpoint)
• HTTP Request: GET
• Path: /posts/1

Speichere den Test-Plan via Cmd+S / Strg+S als jmeter-first-test.jmx. Das ist deine erste versionierbare Test-Datei.

Pro-Tipp: Hardcode niemals Server-Namen, Pfade oder Credentials direkt im Sampler. Nutze User Defined Variables (Test Plan → Add → Config Element → User Defined Variables) oder eine externe config.csv via CSV Data Set Config. So tauschst du Staging und Prod über eine einzelne Datei, und die .jmx bleibt im Repo deploybar.

Listener und Ergebnisse auswerten

Ein Sampler ohne Listener produziert Daten, die niemand sieht. Füge mindestens einen Listener hinzu: Rechtsklick auf Thread Group → Add → Listener → View Results Tree für Detail-Ansicht jedes einzelnen Requests (gut zum Debuggen) und zusätzlich Aggregate Report für die aggregierte Metrik-Auswertung.

Im Aggregate Report siehst du nach dem Run die wichtigen Kennzahlen pro Sampler:

Wichtig: Listener wie View Results Tree sind im Produktions-Lasttest tabu. Sie schreiben jeden Request in den Heap. Bei 10.000 Requests fällt JMeter selbst um. Im GUI zum Debuggen einschalten, im Pipeline-Run deaktivieren und stattdessen die .jtl-Datei via Aggregate Report nachträglich auswerten.

Non-GUI-Mode: JMeter aus der Kommandozeile

Die GUI ist zum Bauen und Debuggen da, nicht zum Lasttesten. Für den echten Test startest du JMeter im Non-GUI-Mode, weil die GUI selbst Ressourcen frisst und Messungen verfälscht:

bin/jmeter -n -t jmeter-first-test.jmx -l results.jtl -e -o report-html/

Was passiert hier:

• -n: Non-GUI Mode
• -t plan.jmx: Test-Plan-Datei
• -l results.jtl: Roh-Ergebnisdatei (CSV, jeder Request eine Zeile)
• -e -o report-html/: Nach dem Run einen HTML-Report aus den Roh-Ergebnissen generieren

Der HTML-Report liegt in report-html/index.html und enthält alle Metriken aus dem Aggregate Report, plus Charts für Antwortzeit über Zeit, aktive Threads und Hits per Second. Versionierbar, automatisierbar, in der Pipeline produzierbar. Genau das brauchst du.

JMeter in CI/CD-Pipelines (Jenkins + GitHub Actions)

Performance-Tests gehören in die Pipeline. Ein Lasttest, der nur manuell läuft, wird zu selten ausgeführt. Regressionen fallen dann erst im Live-Betrieb auf. Qualität ist kein Gate am Ende der Pipeline. Qualität ist die Pipeline.

Jenkinsfile (declarative pipeline) für einen nächtlichen JMeter-Lauf gegen Staging:

pipeline {
  agent any
  triggers { cron('H 2 * * 1-5') }   // werktags nachts 02:xx
  stages {
    stage('JMeter Load Test') {
      steps {
        sh '''
          docker run --rm -v $WORKSPACE:/tests \\
            justb4/jmeter:5.5 \\
            -n -t /tests/plan.jmx \\
            -l /tests/results.jtl \\
            -e -o /tests/report-html/ \\
            -Jhost=staging.example.com \\
            -Jusers=100 -Jrampup=60
        '''
      }
    }
    stage('Publish Report') {
      steps {
        publishHTML([reportDir: 'report-html', reportFiles: 'index.html',
                     reportName: 'JMeter Report'])
      }
    }
  }
  post {
    failure { slackSend channel: '#perf-tests', message: "JMeter-Run fehlgeschlagen: ${env.BUILD_URL}" }
  }
}

GitHub Actions Workflow als Alternative:

name: jmeter-nightly
on:
  schedule:
    - cron: '0 2 * * 1-5'
jobs:
  loadtest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run JMeter
        run: |
          docker run --rm -v ${{ github.workspace }}:/tests \\
            justb4/jmeter:5.5 \\
            -n -t /tests/plan.jmx -l /tests/results.jtl \\
            -e -o /tests/report-html/ \\
            -Jhost=staging.example.com -Jusers=100
      - uses: actions/upload-artifact@v4
        with:
          name: jmeter-report
          path: report-html/

Tiefer in das Jenkins-Setup führt der Artikel Jenkins für Continuous Integration und Continuous Deployment. Für ein größeres CI/CD-Setup-Bild siehe CI/CD-Pipeline-Grundlagen.

JMeter vs. k6 vs. Gatling vs. Locust

JMeter ist nicht die einzige Option. Welches Tool zu dir passt, hängt vom Team, vom Tech-Stack und vom Use-Case ab.

Faustregel: JMeter behalten, wenn dein Team es kennt, du mixed Protokolle (HTTP + JDBC + Kafka) testest oder die codefreie GUI ein Schulungs-Vorteil ist. k6 wählen für neue Greenfield-API-Tests in DevOps-Teams (siehe k6-Performance-Testing-Praxis). Gatling für extreme Last-Anforderungen und JVM-Affinität. Locust wenn dein Team Python-first ist (siehe Locust-Hello-World-Tutorial).

Was sich in JMeter 5.6.3 selbst geändert hat (Bug-Fixes, Java-17-Kompatibilität, Constant-Throughput-Timer-Korrektur), fasse ich im Artikel JMeter Neuerungen zusammen.

Fünf typische Stolperfallen

Aus eigener Praxis (Kunden-Lasttests im Verkehrs- und FSI-Sektor 2024 bis 2026):

1. GUI im Lasttest aktiv lassen. Wer im GUI-Modus 1.000 Threads laufen lässt, misst JMeter, nicht das System. Immer Non-GUI für echte Tests.
2. Heap zu klein. Default ist 1 GB. Bei mehr als 200 Threads erhöhe via HEAP="-Xms2g -Xmx4g" in bin/jmeter. Sonst OutOfMemoryError mitten im Run.
3. View Results Tree im Produktions-Run. Frisst Heap, verfälscht Messungen. Im GUI Debug-Step okay, im Non-GUI-Run löschen oder via "Errors only" einschränken.
4. Constant Throughput Timer falsch verstanden. Der Timer arbeitet pro Minute, nicht pro Sekunde. Wer „60 Requests pro Sekunde" setzen will, trägt 3600 ein, nicht 60.
5. Keine User Defined Variables. Wer Hostnames hardcoded, kann nicht zwischen Staging und Prod schalten ohne die JMX zu ändern. Und damit auch nicht reviewbar deployen.

Fazit

JMeter ist seit über 20 Jahren der De-facto-Standard für Open-Source-Lasttests. Version 5.6.3 zeigt, dass Apache das Tool aktiv pflegt. Die codefreie GUI macht den Einstieg leicht, der Non-GUI-Mode und Docker machen den Pipeline-Einsatz möglich, die Listener und der HTML-Report geben dir reproduzierbare Metriken.

Tools wechseln. Qualitätsdenken bleibt. Ob du am Ende JMeter, k6 oder Gatling fährst, hängt von Team und Tech-Stack ab. Was nicht verhandelbar ist: Performance-Tests müssen in der Pipeline laufen, nicht im manuellen Vor-Release-Sprint untergehen.

Wenn du tiefer ins Konzept hinter Performancetests willst (Lasttest vs. Stresstest vs. Endurance vs. Spike-Test), lies den Performance-Testing-Pillar. Für eine echte Projekt-Lasttest-Variante mit JMeter siehe JMeter-Lasttest-Praxis.

Häufige Fragen zu JMeter (FAQ)

Ist Apache JMeter kostenlos?

Ja. JMeter steht unter der Apache License 2.0 und ist vollständig Open Source. Es gibt keinerlei kommerzielle Lizenzkosten, weder für Entwicklung noch für CI/CD-Einsatz. Plugins aus dem JMeter-Plugins-Repository sind ebenfalls kostenlos.

Welche Java-Version brauche ich für JMeter 5.6.3?

Mindestens Java 8, empfohlen Java 17 LTS oder neuer. Mit modernem JDK ist das Heap-Management deutlich besser, was bei großen Test-Plänen (über 500 Threads) entscheidend ist. Java 21 funktioniert ebenfalls einwandfrei.

Wie viele virtuelle Nutzer schafft JMeter auf einem Laptop?

Realistisch 500 bis 2.000 Threads bei einer Standard-Workstation mit 16 GB RAM, abhängig vom Test-Plan-Komplexität und Sampler-Mix. Für mehr Last nutze distributed JMeter (Master + mehrere Worker) oder ein Cloud-Tool wie BlazeMeter oder unsere eigene Plattform QLoad.

JMeter oder k6: was nehme ich für eine neue Lasttest-Pipeline?

Für neue Greenfield-API-Projekte in DevOps-Teams ist k6 die modernere Wahl: JavaScript-DSL, native Grafana-Integration, kleinere Container-Images. Für gemischte Protokoll-Tests (HTTP + JDBC + Kafka) und Teams ohne Code-Affinität bleibt JMeter die robustere Option. Details im Performance-Testing-Tools-Vergleich.

Wie integriere ich JMeter in Jenkins?

Am saubersten via Docker-Image (justb4/jmeter), das du in einem Stage ausführst und den HTML-Report als Artefakt publishst. Das Performance-Plugin von Jenkins liest .jtl-Dateien direkt und kann Trends über Builds anzeigen. Details im Artikel Jenkins-CI/CD.

Was ist der Unterschied zwischen Lasttest, Stresstest und Endurance-Test?

Lasttest prüft erwartete Produktiv-Last (z.B. 500 gleichzeitige Nutzer). Stresstest fährt die Last über das Erwartete hinaus, bis das System bricht. So findest du die Bruchstelle. Endurance-Test (auch Soak-Test) hält moderate Last über Stunden oder Tage, um Memory Leaks oder Connection-Pool-Erosion zu finden. Vollständige Erklärung im Performance-Testing-Pillar.

Wie versioniere ich JMeter-Test-Pläne im Repository?

Die .jmx-Datei ist XML, versionierbar via Git wie jeder Code. Drei Best Practices: Hostnames und Credentials via User Defined Variables auslagern, CSV-Daten-Dateien neben die JMX legen, große Test-Pläne in mehrere JMX-Dateien zerlegen und via Include Controller einbinden.