Zum Hauptinhalt springen

🚀 Performance Testing

Performance Tests prüfen, ob ein System unter realistischen Bedingungen ausreichend schnell, stabil und skalierbar bleibt.

Funktional korrekt bedeutet nicht performant.

Ein System kann fachlich richtig arbeiten –
und dennoch unter Last kollabieren.

1. Ziel und Einordnung​

1.1 Was sind Performance Tests?​

Performance Tests messen das Verhalten eines Systems unter definierten Lastbedingungen.

Typische Messgrößen:

  • Antwortzeit (Latency)
  • Durchsatz (Requests pro Sekunde)
  • Ressourcenverbrauch (CPU, RAM)
  • Fehlerrate
  • Time to First Byte (TTFB)
  • Largest Contentful Paint (LCP)
  • Interaction to Next Paint (INP)

Performance Tests sind keine funktionalen Tests –
sie prüfen nicht „ob“, sondern „wie gut“.

1.2 Wofür sind Performance Tests da?​

Performance Tests dienen der:

  • Validierung von Lastannahmen
  • Erkennung von Engpässen
  • Absicherung von SLOs
  • Früherkennung von Skalierungsproblemen
  • Vermeidung von Performance-Regressionen

1.3 Was sind Performance Tests nicht?​

Performance Tests sind:

  • kein Ersatz für Monitoring
  • kein einmaliges Projektartefakt
  • kein Tool zur Optimierung ohne Messhypothese
  • kein „wir klicken mal Lighthouse“

Performance ohne Zielmetrik ist wertlos.

2. Arten von Performance Tests​

2.1 Load Testing​

Frage:

Hält das System erwartete Last aus?

Beispiel:

  • 500 gleichzeitige Nutzer
  • 100 Requests pro Sekunde
  • 50 parallele Checkout-Prozesse

2.2 Stress Testing​

Frage:

Was passiert oberhalb der erwarteten Last?

Ziel:

  • Breakpoints erkennen
  • Recovery-Verhalten beobachten
  • Graceful Degradation prüfen

2.3 Soak Testing (Langzeittest)​

Frage:

Bleibt das System über Stunden/Tage stabil?

Erkennt:

  • Memory Leaks
  • Ressourcenerschöpfung
  • schleichende Performance-Degradation

2.4 Frontend Performance (z. B. Lighthouse)​

Relevante Metriken:

  • LCP (Largest Contentful Paint)
  • CLS (Cumulative Layout Shift)
  • INP (Interaction to Next Paint)
  • TTFB

Lighthouse misst primär:

  • Rendering-Performance
  • Bundle-Größe
  • Blocking Resources
  • Accessibility-Basics

Wichtig: Lighthouse ist kein Lasttest – sondern ein Rendering- und Optimierungsindikator.

3. Performance-Budgets​

Performance braucht klare Ziele.

Beispiel:

  • API Response < 200ms (p95)
  • LCP < 2.5s
  • Fehlerrate < 0.1%
  • CPU-Auslastung < 70% unter Normallast

Ohne Budgets gibt es keine objektive Bewertung.

4. Performance als Qualitätsstufen-Thema​

Stufe 1​

  • Keine expliziten Performance-Ziele
  • Optimierung bei Bedarf

Stufe 2​

  • Erste Budgets
  • Basis-Monitoring
  • Lighthouse als Indikator

Stufe 3​

  • SLO-basierte Performance-Messung
  • Lasttests vor größeren Releases
  • p95/p99-Metriken relevant

Stufe 4​

  • Dokumentierte Performance-Anforderungen
  • Reproduzierbare Lasttests
  • Historisierung von Metriken

Stufe 5​

  • Normativ geforderte Performance-Nachweise
  • Auditierbare Testprotokolle

5. Typische Fehler​

  • Nur Durchschnittswerte betrachten (statt p95/p99)
  • Performance-Tests nur einmalig durchführen
  • Lighthouse-Score mit Systemperformance verwechseln
  • Lasttests ohne realistische Daten
  • Keine Produktions-Metriken zum Vergleich

6. Performance vs. Monitoring​

Performance Tests sind:

  • kontrollierte Experimente

Monitoring ist:

  • kontinuierliche Beobachtung im Realbetrieb

Beides ist notwendig.

Monitoring erkennt reale Probleme.
Performance Tests verhindern sie im Vorfeld.

7. Performance im Kontext von Architektur​

Performance ist ein Architekturindikator.

Typische Ursachen für schlechte Performance:

  • Chatty APIs
  • fehlende Caching-Strategien
  • N+1 Queries
  • überdimensionierte Payloads
  • fehlende Asynchronität
  • falsche Indizes

Performance-Probleme sind selten rein „technisch“ – sie sind meist strukturell.

8. Definition of Done (Performance-relevant)​

Ein Feature gilt nicht als fertig, wenn:

  • Performance-Budget verletzt wird
  • Response-Zeiten stark variieren
  • kein Monitoring für kritische Endpunkte existiert
  • Lighthouse-Werte massiv regressieren

Kernaussage​

Performance ist kein Optimierungs-Feintuning.

Sie ist ein Teil der Produktqualität und der Nutzererfahrung.

In Systemen mit wachsender Nutzung, mehreren Teams und AI-generiertem Code ist Performance nicht optional – sie ist eine Skalierungsbedingung.