Load Test in der mobilen Entwicklung — was es ist, Szenarien und Durchführung

Was ist Load Test?

Load Test ist ein Prozess zur Überprüfung, wie ein System unter einer erwarteten Anzahl gleichzeitiger Anfragen oder Benutzer funktioniert. Im Kontext der mobilen Entwicklung wird Load Test sowohl auf der Serverseite (API, Datenbank, Cache) als auch auf der Clientseite (Push-Benachrichtigungsverarbeitung, Datensynchronisation) angewendet. Der Hauptunterschied zu Stresstests besteht darin, dass Load Test eine reale, nicht extreme Last simuliert. Laut AWS Well-Architected Framework (2024) sollten Lasttests mit Lastprofilen durchgeführt werden, die auf realen Nutzungsanalysen basieren.

Load Test kann auf der Ebene von HTTP-Anfragen an die API, WebSocket-Verbindungen oder Datenbanktransaktionen durchgeführt werden. Das Ziel ist sicherzustellen, dass die Antwortzeit jeder Anfrage einen bestimmten Schwellenwert (normalerweise 500–1000 ms für APIs) nicht überschreitet und der Durchsatz (RPS — Anfragen pro Sekunde) die Anforderungen erfüllt. Google Cloud Armor (2024) definiert Schwellenwerte auf Basis von Perzentilen: die p95-Antwortzeit sollte für kritische Endpunkte 2 Sekunden nicht überschreiten.

Lasttests eines mobilen Backends umfassen die Simulation typischer Szenarien: Registrierung, Authentifizierung, Feed-Laden, Formularübermittlung. Szenarien werden als HAR-Dateien (HTTP Archive) aufgezeichnet und vom Lasttest-Tool wiedergegeben. Laut k6-Dokumentation (2025) kann die HAR-Konvertierung die Vorbereitungszeit für den Load Test um 60% reduzieren.

Ziele des Lasttests

Das erste Ziel des Load Tests ist die Bestätigung des Systemdurchsatzes. Wenn die Spezifikation die Verarbeitung von 1000 RPS erfordert, muss der Lasttest dies mit einer Reserve von 20% bestätigen. Laut Netflix Tech Blog (2024) werden Lasttests bei Netflix mit einer 2-fachen Reserve der Spitzenlast durchgeführt: wenn 10000 RPS erwartet werden, prüft der Test 20000 RPS. Dieser Ansatz garantiert Stabilität bei plötzlichen Verkehrsspitzen.

Das zweite Ziel ist die Identifizierung von Engpässen (Bottlenecks) in der Architektur. Typische Engpässe in mobilen Backends sind die Datenbank (langsame Abfragen), der Cache (falsche Invalidierungsstrategie) und externe APIs (langsame Dienste Dritter). Distributed Tracing (Jaeger, Zipkin) hilft, das Problem auf der Ebene eines bestimmten Dienstes oder einer bestimmten Anfrage zu lokalisieren.

Das dritte Ziel ist die Bestimmung des Sättigungspunkts (Saturation Point). Dies ist der Moment, in dem das Hinzufügen neuer Benutzer den Durchsatz nicht mehr erhöht. In mobilen Anwendungen tritt der Sättigungspunkt oft bei 70–80% CPU-Auslastung auf den Datenbankservern auf. Auto-Scaling sollte vor Erreichen dieses Punktes ausgelöst werden.

Lasttestszenarien

Spitzentest (Spike Test) — simuliert einen plötzlichen Aktivitätsanstieg, wie eine morgendliche Push-Benachrichtigungskampagne oder den Start einer Werbekampagne. Laut Grafana k6 (2025) simuliert der Spike Test ein Lastwachstum von 100 auf 10000 RPS in 30 Sekunden. Das System muss dies bewältigen, ohne Anfragen zu verlieren und ohne die Antwortzeit um mehr als 50% zu überschreiten.

Ausdauertest (Endurance Test) — überprüft die Systemstabilität bei längerem Betrieb unter Last. Die typische Dauer beträgt 1–4 Stunden. Der Endurance Test deckt Speicherlecks in Serveranwendungen, Probleme mit dem Datenbankverbindungspool und die Verschlechterung der Cache-Leistung auf. Der PostgreSQL-Verbindungspool kann bei längerer Last ohne ordnungsgemäße Konfiguration innerhalb von 2–3 Stunden Betriebszeit verfügbare Verbindungen erschöpfen.

Stufenlasttest (Step Load Test) — schrittweise Laststeigerung um 10–20% alle 2–5 Minuten. Dieses Szenario hilft, die genaue Grenze zu finden, nach der das System degradiert. InfluxDB und Prometheus sammeln Metriken bei jedem Schritt, um ein Diagramm der Antwortzeit gegenüber RPS zu erstellen.

Load Test Metriken

Antwortzeit

Antwortzeit ist die primäre Metrik des Load Tests. Sie wird in Millisekunden gemessen und nach Perzentilen analysiert: p50 (Median), p95 und p99. Google SRE (2024) empfiehlt einen p95-Schwellenwert von nicht mehr als 1000 ms für REST-APIs und nicht mehr als 200 ms für gRPC. Perzentile sind wichtiger als Durchschnittswerte, da sie das Verhalten der schlechtesten Anfragen zeigen, die Benutzer zuerst bemerken. Apdex (Application Performance Index) ist eine zusammengesetzte Metrik, die den Anteil zufriedener, tolerierender und frustrierter Benutzer berücksichtigt.

Durchsatz

Durchsatz (Throughput) — die Anzahl erfolgreicher Anfragen pro Zeiteinheit. Gemessen in RPS (Anfragen pro Sekunde) oder TPS (Transaktionen pro Sekunde). Der Durchsatzgraph in den Koordinaten „Zeit — RPS“ sollte bis zum Sättigungspunkt linear sein. Ein steiler Abfall des Durchsatzes bei steigender Last ist ein Zeichen dafür, dass die Systemgrenze erreicht ist. Apache Bench und wrk sind einfache CLI-Werkzeuge für schnelle Durchsatzprüfungen während der Entwicklung.

Fehlerrate

Fehlerrate (Error Rate) — der Anteil der Antworten mit HTTP-Status 4xx oder 5xx an der Gesamtzahl der Anfragen. Die akzeptable Schwelle liegt bei unter 1%. Fehler 429 (Too Many Requests) und 503 (Service Unavailable) unter hoher Last weisen auf die Notwendigkeit hin, Rate Limiting und Auto-Scaling zu konfigurieren. Ein Ratenbegrenzer auf der API-Gateway-Seite schützt das Backend vor Überschreitung der zulässigen Last. Die Wiederholungsrichtlinie mit exponentiellem Backoff hilft Clients, temporäre Fehler korrekt zu behandeln.

Werkzeuge für Load Test

k6 (Grafana)

k6 — das führende Open-Source-Lasttest-Tool von Grafana. Skripte werden in JavaScript geschrieben und unterstützen modulare Szenarien, Schwellenwerte (Thresholds) und die Integration mit Prometheus und InfluxDB. k6 kann sowohl in der CLI als auch in der Grafana Cloud k6 ausgeführt werden. Grafana Cloud erstellt automatisch Dashboards aus den Load-Test-Ergebnissen und vergleicht sie mit historischen Daten. k6 unterstützt Protocol Buffers und gRPC über das separate Modul k6/net/grpc.

Apache JMeter

Apache JMeter — ein klassisches Load-Test-Tool mit grafischer Oberfläche. Es unterstützt eine breite Palette von Protokollen: HTTP, JDBC, JMS, FTP und TCP. JMeter eignet sich besser für komplexe Szenarien mit vielen verschiedenen Anfragetypen, erfordert jedoch mehr manuelle Konfiguration im Vergleich zu k6. JMeter-Plugins erweitern die Funktionalität für WebSocket- und gRPC-Tests. Für den verteilten Einsatz verwendet JMeter eine Master-Slave-Architektur mit einem Controller.

Locust

Locust — ein Python-basiertes Tool, das die Beschreibung von Lastszenarien im Code ermöglicht. Locust ist praktisch für Teams, die Python als ihre primäre Automatisierungssprache verwenden. Im Gegensatz zu k6 und JMeter unterstützt Locust verteilte Ausführung von Haus aus: ein Master-Knoten koordiniert mehrere Worker-Knoten. Verteilte Ausführung ermöglicht die Erzeugung von Lasten von bis zu 100000 RPS von mehreren Maschinen. Locust unterstützt auch WebSocket-Tests über benutzerdefinierte Erweiterungen.

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

Beispiel für einen Load Test in k6

Das oben gezeigte k6-Skript demonstriert eine typische Lastteststruktur. Options definiert das Lastprofil: Hochfahren (Ramp-up) für 2 Minuten auf 100 Benutzer, dann 5 Minuten konstante Last und erneutes Hochfahren auf 200 Benutzer. Thresholds definieren die Testbestandskriterien: p95-Anfragezeit nicht mehr als 500 ms, Fehlerrate unter 1%. Wenn Schwellenwerte überschritten werden, beendet sich k6 mit einem Code ungleich Null — dies ermöglicht die Integration des Load Tests in CI/CD.

In der mobilen Entwicklung ist der Load Test der Serverseite besonders wichtig beim Start neuer Funktionen, die zusätzliche Last erzeugen: Likes, Kommentare, Streaming. Empfehlung — führen Sie vor jedem Deployment in die Produktion einen Load Test auf jedem Staging durch. Die Erstellung eines Basis-Lastprofils in der API-Designphase hilft, architektonische Probleme in späteren Phasen zu vermeiden.