Performance
Performance beschreibt zeitliches Verhalten und Kapazität eines Systems. Aussagekräftige Messungen nennen Last, Messpunkt und Einheit.
- AntwortzeitDauer vom Klick bis zur Bestätigung.
- DurchsatzWie viel das System pro Sekunde schafft.
- LastkontextJeder Wert braucht dieselbe Last.
Einordnung
Warum das wichtig ist
Eine Zahl ohne Last, Messpunkt und Einheit lässt sich nicht prüfen. Perzentile zeigen Ausreißer, die der Median verdeckt. Kurz vor der Sättigung steigt die Antwortzeit sprunghaft, weil Anfragen warten.
Hier legst du fest und misst, wie schnell und in welchem Umfang das System Anfragen verarbeitet. Wie die Architektur das erreicht, zeigen die Taktiken unten; Zustände unter Last behandeln Backpressure und Timeout.
Auf einen Blick · Last, Antwortzeit und Durchsatz
Performance-Messung bei steigender Last
Das Team misst den Abschluss einer Bestellung mit illustrativen Testdaten. Die Messung umfasst Shop-Verarbeitung und simulierte Antwort des Zahlungsanbieters.
So liest du das Bild
- Antwortzeit Median und 95. Perzentil steigen, sobald du die Last erhöhst.
- Durchsatz Die Zeile Durchsatz hört bei 24 Bestellungen/s auf zu wachsen.
- Lastkontext Jede Stufe nennt die Last; erst damit sind die vier Werte vergleichbar.
Taktiken
So erreicht die Architektur das Ziel
Dieser Baustein legt fest und misst, wie schnell und wie viel das System verarbeitet; die Taktiken unten sind eigene Bausteine, die dieses Ziel erreichen.
Last senken
Der Shop beantwortet häufige Katalogabfragen aus gespeicherten Ergebnissen statt aus der Datenbank.
Last steuern
Bestellspitzen werden angenommen und gleichmäßig abgearbeitet, statt das System zu überrollen.
Ressourcen verteilen
Bestell- und Katalogdaten liegen auf mehreren Einheiten, sodass Lesen und Schreiben sich verteilen.
Nutzen & Grenzen
Hilft, wenn
- Eine erwartete Lastspitze verlangt einen Nachweis für Antwortzeit und Verarbeitungskapazität.
- Antwortzeiten steigen und die Ursache muss entlang von Aufrufen und Ressourcen eingegrenzt werden.
Grenzen
- Ein Lasttest misst nur das getestete Profil: Echte Datenmengen, kalte Caches und Netzwerkschwankungen verschieben die Werte in Produktion. Miss im Betrieb mit SLIs nach.
- Mehr Kapazität kann Kosten erhöhen, ohne den Engpass zu beseitigen. Finde den Engpass zuerst: Miss Ressourcen und Wartezeiten pro Abhängigkeit und verfolge das Ergebnis als SLI.
In der Praxis
- Messpunkt und Lastprofil festlegen. Bestimme, wann die Messung beginnt und endet und welche parallele Nutzung sie abbildet. Das Ergebnis macht verschiedene Läufe vergleichbar.
- Ablauf und Ressourcen instrumentieren. Erfasse Antwortzeitverteilung, Durchsatz und Auslastung entlang der beteiligten Schritte. Verknüpfe diese Werte mit einem messbaren Qualitätsattribut.
- Eine Ursache ändern und erneut messen. Verändere gezielt den ermittelten Engpass und wiederhole denselben Test. Ein SLI kann anschließend zeigen, ob die Verbesserung auch im Betrieb anhält.
Ausführliche Erklärung lesen
Antwortzeit beschreibt die Dauer einer einzelnen Anfrage, Durchsatz die Zahl verarbeiteter Vorgänge pro Zeit. Ressourcenverbrauch zeigt, welche Kapazität diese Leistung benötigt. Die Werte hängen von Lastprofil, Datenmenge und Abhängigkeiten ab. Qualitätsattribute liefern das übergeordnete Szenario; SLIs, SLOs & Error Budgets ordnen Messung und Zielwerte in den Betrieb ein.
Durchschnittswerte können langsame Randfälle verdecken. Perzentile und repräsentative Lastprofile zeigen, wie viele Nutzer von Verzögerungen betroffen sind. Eine Messung entlang des vollständigen Ablaufs hilft, den Engpass von Symptomen zu unterscheiden. Kapazitätserhöhung ist erst dann wirksam, wenn sie die gemessene Ursache adressiert.
Littles Gesetz (Little's Law) verbindet die drei Größen: Die Zahl gleichzeitig bearbeiteter Vorgänge entspricht dem Durchsatz mal der Antwortzeit. Im Shop sind das bei 20 Anfragen/s und 0,42 s etwa 8 Bestellungen gleichzeitig. Daraus leitest du die Größe von Thread-Pools und Verbindungen ab.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Bei welcher Last überschreitet das 95. Perzentil 800 ms, was macht der Durchsatz dort, und was zeigt die CPU?
Lösung mit Begründung ansehen
Bei 30 Anfragen/s (2.600 ms). Der Durchsatz bleibt bei 24 Bestellungen/s stehen, die CPU liegt bei etwa 66 % und hat noch Luft.
AnwendenAuf eine neue Lage übertragen
Das Team will bei 30 Anfragen/s doppelt so viele CPU-Kerne buchen. Was prüfst du vorher?
Lösung mit Begründung ansehen
Die CPU liegt bei etwa 66 % und ist nicht der Engpass. Miss zuerst Wartezeiten und Verbindungen zum Zahlungsanbieter, z. B. mit der USE-Methode (Auslastung, Sättigung, Fehler pro Ressource).
BewertenEine Alternative abwägen
Soll das Team nur den Median berichten, weil er sich gut vermitteln lässt?
Lösung mit Begründung ansehen
Der Median ist einfach und stabil. Er verdeckt jedoch die langsamsten Antworten. Zusammen mit dem 95. Perzentil zeigt er, wie sich der typische Fall und der langsame Rand unterscheiden.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Microsoft · Performance Antipatterns (öffnet in neuem Tab)Beschreibt typische Leistungsprobleme und ihre Ursachen.
- Brendan Gregg · USE Method (öffnet in neuem Tab)Prüft pro Ressource Auslastung, Sättigung und Fehler, um Engpässe systematisch zu finden.
- arc42 · Qualitätsmodell: Time Behaviour (öffnet in neuem Tab)Ordnet Antwort-, Verarbeitungs- und Durchsatzzeiten im Qualitätsmodell ein.