Performance Testing

Warum Performance Testing¶

Ihre Anwendung funktioniert perfekt mit 10 Nutzern. Was passiert mit 10.000? Mit 50.000 am Black Friday? Was wenn das Marketing-Team eine Kampagne startet und der Traffic sich innerhalb einer Stunde verzehnfacht?

Performance-Probleme sind tueckisch. Sie zeigen sich nicht in der Entwicklungsumgebung. Nicht im Code Review. Nicht in Unit Tests. Sie zeigen sich in Produktion, unter realer Last, wenn es zu spaet ist etwas zu reparieren.

Jede zusaetzliche Sekunde kostet Geld. Amazon stellte fest, dass 100ms zusaetzliche Latenz den Umsatz um 1% senkt. Google zeigte, dass eine Seite die 3 Sekunden zum Laden braucht 53% der mobilen Besucher verliert. Netflix investiert Millionen in Performance Testing — weil die Alternative Kundenverlust ist.

Performance Testing ist kein Luxus. Es ist eine Versicherung gegen den teuersten Incident-Typ — eine langsame oder nicht verfuegbare Anwendung.

Arten von Performance Tests¶

Jeder Typ beantwortet eine andere Frage. Eine vollstaendige Performance-Strategie kombiniert alle.

Load Testing¶

Frage: Kann das System den erwarteten Verkehr bewaeltigen?

Ein Load Test simuliert reale Last — typische Nutzerzahl, typische Operationen, typische Datenvolumen. Wir messen Antwortzeit, Durchsatz, Fehlerrate und Ressourcennutzung.

Stress Testing¶

Frage: Wo liegt das Limit und was passiert wenn wir es ueberschreiten?

Ein Stress Test steigert die Last schrittweise ueber das erwartete Niveau. 100% → 150% → 200% → 300% des normalen Traffics. Wir suchen den Bruchpunkt — wo beginnt das System zu degradieren? Wo faellt es aus? Und entscheidend: wie erholt es sich?

Spike Testing¶

Frage: Kann das System einen ploetzlichen Traffic-Anstieg bewaeltigen?

Wir simulieren einen scharfen Spike — von 500 auf 5.000 Nutzer in 30 Sekunden. Typische Szenarien: Push-Benachrichtigungen (alle oeffnen die App gleichzeitig), viraler Content, Flash Sales, Live-Sportergebnisse.

Soak Testing (Dauertests)¶

Frage: Haelt das System konstante Last ueber laengere Zeit aus?

Laeuft Stunden oder Tage unter normaler Last. Deckt Memory Leaks, Connection Pool Exhaustion, Festplattenspeicher-Probleme, Log-Rotation-Probleme, Garbage-Collection-Degradation auf.

Breakpoint Testing¶

Frage: Was ist die maximale Kapazitaet des Systems?

Wir inkrementieren automatisch die Last bis SLAs verletzt werden. Ergebnis: eine exakte Kapazitaetszahl. „Das System bewaeltigt 8.200 gleichzeitige Nutzer bei p95 < 500ms.” Kapazitaetsplanung basierend auf Daten, nicht Vermutungen.

k6 — unser primaeres Tool¶

k6 von Grafana Labs kombiniert einfaches Testschreiben in JavaScript mit der Performance einer Go-Runtime. Ideal fuer moderne API-first-Architekturen und CI/CD-Integration.

Warum k6¶

JavaScript/TypeScript: Sie schreiben Tests in einer Sprache, die Ihr Team bereits kennt. Kein DSL, keine neue Sprache.

Performance: Die Go-Runtime bewaeltigt Tausende virtueller Nutzer auf einer Maschine. 10.000 gleichzeitige Verbindungen ohne Probleme.

CI/CD-nativ: CLI-Tool mit Exit-Codes basierend auf Schwellenwerten. k6 run --threshold 'http_req_duration{p(95)<500}' — Test schlaegt fehl wenn p95 500ms ueberschreitet.

Grafana-Integration: Ergebnisse direkt ins Grafana-Dashboard. Echtzeit-Visualisierung waehrend des Tests. Historischer Vergleich.

k6-Test-Beispiel¶

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },   // ramp up
    { duration: '5m', target: 100 },   // steady state
    { duration: '2m', target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('https://api.example.com/products');
  check(res, {
    'status 200': (r) => r.status === 200,
    'response < 500ms': (r) => r.timings.duration < 500,
  });
  sleep(1);
}

Lesbar, versionierbar, ausfuehrbar in CI. Kein GUI, kein Vendor Lock-in.

Performance Budgets¶

Ein Performance Budget ist ein Limit, das nicht ueberschritten werden darf. Wie ein Finanzbudget — aber fuer Geschwindigkeit.

Enforcement¶

Performance Budgets ohne Enforcement sind nur Wuensche. Wir setzen sie durch:

• CI/CD Gates: k6 Thresholds, Lighthouse CI, Webpack Bundle Analyzer — Budget-Ueberschreitung = fehlgeschlagener Build
• Monitoring Alerts: Prometheus-Alerts bei Ueberschreitung von Produktions-Budgets
• Review-Prozess: Performance Impact Assessment fuer architektonische Aenderungen

Engpass-Analyse¶

Ein Performance Test deckt das Symptom auf (langsame Antwort). Engpass-Analyse findet die Ursache.

Haeufige Engpaesse¶

Datenbank: N+1-Abfragen, fehlende Indizes, Full Table Scans, Lock Contention, Connection Pool Exhaustion. Loesungen: Query-Optimierung, Indizierung, Connection Pooling, Read Replicas, Caching.

Speicher: Memory Leaks, GC-Druck, ueberdimensionierte Caches, unbegrenzte Puffer. Loesungen: Profiling, Heap Dumps, speichereffiziente Datenstrukturen.

Netzwerk: DNS-Aufloesung, TLS-Handshake, geschwatzige Microservices, grosse Payloads. Loesungen: Connection Pooling, gRPC, Payload-Kompression, CDN.

Concurrency: Thread Pool Exhaustion, Async-Engpaesse, Lock Contention, Event Loop Blocking. Loesungen: async/await, Non-blocking I/O, Lock-freie Strukturen.

Wie wir zusammenarbeiten¶

1. Baseline — wir messen die aktuelle Performance und identifizieren kritische Flows
2. Testszenarien — wir entwerfen Lastprofile basierend auf Produktionsdaten
3. Ausfuehrung — wir fuehren eine Batterie von Tests durch (Load, Stress, Spike, Soak)
4. Analyse — wir identifizieren Engpaesse und schlagen Optimierungen vor
5. Optimierung — wir implementieren Fixes, testen erneut, vergleichen
6. CI/CD-Integration — Performance Tests als Teil der Pipeline, Budgets als Gates
7. Kapazitaetsplan — wie viele Nutzer Sie bewaeltigen, wann Sie skalieren muessen

Stack¶

Load Testing: k6, Gatling, Artillery, Locust, JMeter (Legacy).

Frontend Performance: Lighthouse, WebPageTest, Core Web Vitals.

Profiling: async-profiler (Java), py-spy (Python), pprof (Go), Chrome DevTools.

Monitoring: Prometheus + Grafana fuer Echtzeit-Visualisierung waehrend Tests.

CI/CD: GitHub Actions, GitLab CI — Performance Gates in der Pipeline.

Verwandt mit