Brendan Greggs Methoden zur Analyse von Latenz und zum Profiling

Warum Brendan Greggs Ansatz Rate- und Bauchgefühl reduziert

Brendan Gregg ist einer der einflussreichsten Stimmen im Bereich Systemperformance, besonders im Linux-Umfeld. Er hat weit verbreitete Bücher geschrieben, praktische Werkzeuge entwickelt und—am wichtigsten—klare Methoden geteilt, um echte Produktionsprobleme zu untersuchen. Teams übernehmen seinen Ansatz, weil er unter Druck funktioniert: wenn die Latenz steigt und alle Antworten erwarten, braucht man einen Weg, von „vielleicht ist es X“ zu „es ist definitiv Y“ zu kommen — mit möglichst wenig Drama.

Was „Performance-Methodik“ wirklich bedeutet

Eine Performance-Methodik ist kein einzelnes Tool oder ein cleverer Befehl. Es ist eine wiederholbare Vorgehensweise: eine Checkliste, was man zuerst betrachtet, wie man das Gesehene interpretiert und wie man entscheidet, was als Nächstes zu tun ist.

Diese Wiederholbarkeit reduziert das Raten. Anstatt sich auf die Person mit der meisten Intuition (oder der lautesten Meinung) zu verlassen, folgt man einem konsistenten Prozess, der:

• das Problem auf eine konkrete Ressource, einen Service oder einen Codepfad eingrenzt
• das misst, was im gleichen Zeitfenster wie der Vorfall passiert
• den Engpass durch Beweise bestätigt, bevor Änderungen vorgenommen werden

Der häufige Fehler: beheben bevor gemessen wird

Viele Latenz-Untersuchungen gehen in den ersten fünf Minuten schief. Leute springen sofort zu Maßnahmen: „mehr CPU“, „Service neu starten“, „Cache vergrößern“, „GC tunen“, „es muss das Netzwerk sein“. Manchmal helfen diese Aktionen—oft verdecken sie das Signal, verschwenden Zeit oder bringen neue Risiken.

Greggs Methoden drängen dazu, „Lösungen“ aufzuschieben, bis man einfachere Fragen beantworten kann: Was ist ausgelastet? Was erzeugt Fehler? Was ist langsamer geworden — Durchsatz, Warteschlangen oder einzelne Operationen?

Was dieser Leitfaden Ihnen hilft zu tun

Dieser Leitfaden hilft, den Umfang einzugrenzen, die richtigen Signale zu messen und den Engpass zu bestätigen, bevor Sie optimieren. Ziel ist ein strukturiertes Vorgehen zur Untersuchung von Latenz- und Profiling-Problemen in Produktion, sodass Ergebnisse nicht vom Glück abhängen.

Latenz-Grundlagen: was Sie messen sollten, bevor Sie tunen

Latenz ist ein Symptom: Nutzer warten länger, bis Arbeit fertig ist. Die Ursache liegt meist woanders — CPU-Contention, Festplatten- oder Netzwerkwartezeiten, Sperr-Contention, Garbage Collection, Queuing oder Verzögerungen bei entfernten Abhängigkeiten. Latenz allein zu messen sagt Ihnen nur, dass Schmerz besteht, nicht wo er herkommt.

Durchsatz, Latenz und Fehler bewegen sich zusammen

Diese drei Signale sind gekoppelt:

• Durchsatz (Requests/Sekunde) steigt und kann Queuing erhöhen, was die Latenz erhöht.
• Fehler können die beobachtete Latenz verringern (schnelle Fehler) oder erhöhen (Retries und Timeouts).
• Durch Begrenzung des Durchsatzes (Rate Limits, Backpressure) kann man die Tail-Latenz verbessern, während weniger Anfragen erfolgreich sind.

Erfassen Sie vor dem Tuning alle drei Signale für dasselbe Zeitfenster. Ansonsten könnten Sie Latenz „reparieren“, indem Sie Arbeit verwerfen oder schneller fehlschlagen lassen.

Vertraue nicht den Durchschnittswerten: Perzentile und Tail-Latenz

Der Durchschnitt verschleiert Spitzen, die Nutzer erinnern. Ein Service mit 50 ms Durchschnitt kann dennoch häufige 2 s-Stalls haben.

Verfolgen Sie Perzentile:

• p50: typische Nutzererfahrung
• p95/p99: Tail-Latenz (wo die meisten Probleme auftreten)

Beobachten Sie auch die Form der Latenz: ein stabiler p50 mit steigendem p99 deutet oft auf intermittierende Stalls hin (z. B. Sperr-Contention, I/O-Hänger, Stop-the-world-Pausen) statt auf eine allgemeine Verlangsamung.

Latenz-Budgets: wo Zeit erlaubt ist hinzufließen

Ein Latenz-Budget ist ein einfaches Abrechnungsmodell: „Wenn die Anfrage in 300 ms fertig sein muss, wie darf Zeit verteilt werden?“ Teilen Sie es in Buckets wie:

• Zeit in Ihrem Service (Berechnung + Warten)
• Zeit in downstream Services
• Zeit in Datenbanken/Caches
• Netzwerk-Transit und TLS
• Zeit in Warteschlangen (Threads, Connection Pools, Load Balancer)

Dieses Budget strukturiert die erste Messaufgabe: identifizieren Sie, welcher Bucket während des Spitzenereignisses gewachsen ist, und untersuchen Sie diesen Bereich statt blind zu tunen.

Beginnen Sie mit einer klaren Frage und einem definierten Umfang

Latenz-Analysen geraten aus dem Ruder, wenn das „Problem“ als das System ist langsam beschrieben wird. Greggs Methoden beginnen früher: zwingen Sie die Fragestellung in eine konkrete, testbare Frage.

Definieren Sie, was „langsam“ bedeutet (und für wen)

Schreiben Sie zwei Sätze auf, bevor Sie ein Tool anfassen:

• Was ist langsam? (Seitenladezeit, API-Endpunkt, Batch-Job, Login, Checkout, eine spezifische SQL-Abfrage)
• Wo wird die Langsamkeit beobachtet? (Kunden-Browser, Mobile App, eine Region, ein Pod, ein Host, ein interner Service)

Das verhindert, dass Sie die falsche Schicht optimieren — z. B. Host-CPU — wenn der Schmerz auf einen Endpunkt oder eine downstream-Abhängigkeit beschränkt ist.

Wählen Sie ein Zeitfenster und einen Scope

Wählen Sie ein Fenster, das zur Beschwerde passt und idealerweise eine „gute“ Vergleichsperiode enthält.

Begrenzen Sie Ihren Scope explizit:

• Host vs. Service vs. Endpoint: „Ein Kubernetes-Node“ ist anders als „eine API-Route“.
• Welche Traffic-Scheibe: Region, Kundentier, nur fehlerhafte Requests oder alle Requests.
• Welches Signal hat den Bericht ausgelöst: p95-Latenz, Timeouts, Queue-Tiefe oder User-Timing.

Präzision hier macht spätere Schritte (USE, RED, Profiling) schneller, weil Sie wissen, welche Daten sich ändern sollten, wenn Ihre Hypothese stimmt.

Behandeln Sie kürzliche Änderungen als Hypothesen, nicht als Antworten

Notieren Sie Deploys, Konfigurationsänderungen, Traffic-Verschiebungen und Infrastruktur-Events — aber nehmen Sie keine Kausalität an. Formulieren Sie sie als „Wenn X, dann würden wir Y erwarten“, damit Sie schnell bestätigen oder verwerfen können.

Führen Sie ein leichtgewichtiges Untersuchungs-Log

Ein kleines Log verhindert doppelte Arbeit im Team und erleichtert Übergaben.

Time | Question | Scope | Data checked | Result | Next step

Schon fünf Zeilen wie diese können ein stressiges Incident in einen wiederholbaren Prozess verwandeln.

Die USE-Methode: ein schneller Inventar-Check auf Ressourcen-Engpässe

Die USE-Methode (Utilization, Saturation, Errors) ist Greggs schnelle Checkliste, um die „großen vier“ Ressourcen — CPU, Speicher, Festplatte (Storage) und Netzwerk — zu scannen, damit Sie aufhören zu raten und beginnen, das Problem einzugrenzen.

Was sie ist: eine Checkliste pro Ressource

Anstatt Dutzende Dashboards zu starren, stellen Sie für jede Ressource dieselben drei Fragen:

• Utilization: Wie beschäftigt ist sie gerade?
• Saturation: Staut sich Arbeit (Warteschlangen, Wartezeit), auch wenn die Auslastung nicht maximal ist?
• Errors: Schlägt sie fehl oder wiederholt sie Versuche auf eine Weise, die Verzögerungen verursacht?

Konsistent angewendet wird das zu einem schnellen Inventar, wo „Druck“ existiert.

Wie man sie praktisch anwendet

Für CPU ist Utilization der CPU-Busy-%, Saturation zeigt sich als Run-Queue-Druck oder Threads, die auf Ausführung warten, und Errors können Throttling in Containern oder fehlerhafte Interrupts sein.

Für Speicher ist Utilization genutzter Speicher, Saturation zeigt sich als Paging oder häufige Garbage Collection, und Errors umfassen Allokationsfehler oder OOM-Events.

Für Festplatte ist Utilization die Device-Busy-Zeit, Saturation ist Queue-Depth und Read/Write-Wartezeit, und Errors sind I/O-Fehler oder Timeouts.

Für Netzwerk ist Utilization Durchsatz, Saturation sind Drops/Queues/Latenz und Errors sind Retransmits, Resets oder Paketverlust.

Am nützlichsten während Latenz-Vorfällen

Bei Nutzerberichten über Langsamkeit sind oft Saturation-Signale am aufschlussreichsten: Warteschlangen, Wartezeit und Contention korrelieren tendenziell direkter mit Latenz als rohe Auslastung.

USE ergänzt Service-Metriken (sie ersetzt sie nicht)

Service-Level-Metriken (wie Request-Latenz und Fehlerquote) sagen Ihnen den Impact. USE sagt Ihnen, wo Sie als Nächstes schauen sollten, indem es die Ressource identifiziert, die unter Druck steht.

Eine praktische Schleife ist:

1. Bestätigen Sie den Nutzer-Impact (Duration/Errors)
2. Führen Sie das USE-Inventar aus
3. Zoomen Sie in die verdächtige Ressource mit tieferem Werkzeug (Profiles, Traces, Kernel-Stats)

Die RED-Methode: service-zentrierte Signale, die auf Impact zeigen

Die RED-Methode hält Sie an der Nutzererfahrung orientiert, bevor Sie in Host-Grafiken abtauchen.

• Rate: wie viele Requests pro Sekunde Ihr Service oder Endpunkt verarbeitet
• Errors: wie viele Requests fehlschlagen (und was „Fehler“ für Ihre App bedeutet)
• Duration: wie lange erfolgreiche Requests dauern (als Perzentile, nicht als Durchschnitt)

Warum RED Ihnen hilft zu priorisieren

RED verhindert, dass Sie „interessanten“ Systemmetriken hinterherjagen, die die Nutzer nicht betreffen. Es erzwingt eine engere Schleife: Welcher Endpunkt ist langsam, für welche Nutzer und seit wann? Wenn die Duration nur bei einer Route steigt, während die gesamte CPU flach bleibt, haben Sie schon einen schärferen Startpunkt.

Eine nützliche Gewohnheit: Halten Sie RED nach Service und Top-Endpunkten getrennt. Das macht es einfach, eine breite Verschlechterung von einer lokalen Regression zu unterscheiden.

RED-Symptome auf USE-Checks abbilden

RED sagt Ihnen wo der Schmerz ist. USE hilft zu testen, welche Ressource verantwortlich ist.

Beispiele:

• Duration steigt + Rate stabil → prüfen Sie Saturation/Queuing: CPU run queue, Storage-Latenz, DB-Connection-Pools.
• Errors steigen + Duration steigt → prüfen Sie Timeouts und Retries: überlastete Downstreams, Threadpools, Netzwerkdrops.
• Rate steigt + Duration steigt → prüfen Sie Kapazitätsgrenzen: CPU-Auslastung, Load-Balancer-Verhalten, Verzögerungen beim Autoscaling.

Ein minimales „was hat sich geändert?“ Dashboard

Halten Sie das Layout fokussiert:

1. RED-Übersicht: Rate, Errors und p50/p95/p99 Duration für den Service.
2. Top-Endpunkte: dieselben RED-Signale pro Endpunkt, sortiert nach Traffic oder schlechtester p95.
3. Abhängigkeiten: RED-artige Panels für große Downstreams (DB, Cache, externe APIs).
4. Eine Korrelationsreihe: eine kleine Menge Systemmetriken (CPU, Speicherdruck, Disk-I/O-Latenz, Netzwerk-Retransmits), um den Sprung von Service-View zur Ursachenprüfung zu beschleunigen.

Wenn Sie einen konsistenten Incident-Workflow wollen, koppeln Sie diesen Abschnitt mit dem USE-Inventar unter /blog/use-method-overview, damit Sie von „Nutzer fühlen es“ zu „diese Ressource ist die Einschränkung“ mit weniger Hin- und Herspringen kommen.

Priorisierung: wählen Sie die nächstbeste Frage

Eine Performance-Untersuchung kann in Minuten zu Dutzenden Charts und Hypothesen explodieren. Greggs Denkweise ist, es eng zu halten: Ihre Aufgabe ist nicht „mehr Daten zu sammeln“, sondern die nächste Frage zu stellen, die am schnellsten Unsicherheit eliminiert.

Die 80/20-Regel für Engpässe

Die meisten Latenzprobleme werden von einer dominanten Kostenstelle (oder einem kleinen Paar) dominiert: eine heiße Sperre, eine langsame Abhängigkeit, eine überlastete Festplatte, ein GC-Pausenmuster. Priorisierung bedeutet, diese dominante Kostenstelle zuerst zu suchen, weil 5 % Verkürzung an fünf verschiedenen Stellen selten die für den Nutzer sichtbare Latenz bewegt.

Ein praktischer Test: „Was könnte den größten Teil der Latenzänderung erklären?“ Wenn eine Hypothese nur einen winzigen Anteil erklären kann, ist sie niedriger priorisiert.

Top-down vs. bottom-up: wo starten

Benutzen Sie Top-down, wenn Sie beantworten wollen „Sind Nutzer betroffen?“ Starten Sie bei Endpunkten (RED-Signale): Latenz, Durchsatz, Fehler. Das hilft, zu vermeiden, etwas zu optimieren, das nicht auf dem kritischen Pfad liegt.

Benutzen Sie Bottom-up, wenn der Host offensichtlich krank ist (USE-Symptome): CPU-Sättigung, nicht kontrollierbarer Speicherdruck, I/O-Wartezeiten. Wenn ein Node ausgelastet ist, verschwenden Sie Zeit, wenn Sie nur Endpoint-Perzentile anstarren, ohne die Beschränkung zu verstehen.

Ein einfacher Entscheidungsbaum, der Thrash verhindert

Wenn ein Alert kommt, wählen Sie einen Zweig und bleiben Sie dabei, bis Sie ihn bestätigen oder falsifizieren:

• Latenzspike + Fehleranstieg → „Ist das ein Abhängigkeits- oder Kapazitätsereignis?“ (Timeouts, Connection-Pool-Erschöpfung, downstream 5xx)
• Latenzspike + CPU-Spike → „Macht die CPU nützliche Arbeit oder ist sie blockiert?“ (on-CPU vs off-CPU time)
• Latenzspike + hohe I/O-Wartezeit → „Welches Gerät oder Dateisystem staut auf?“
• Latenzspike ohne Ressourcen-Spikes → „Worauf wird gewartet?“ (Sperren, Scheduler, Netzwerk, entfernte Aufrufe)

Vermeiden Sie Metrik-Überladung, bleiben Sie systematisch

Beschränken Sie sich auf einen kleinen Startsatz an Signalen und bohren Sie nur dann tiefer, wenn sich etwas bewegt. Wenn Sie eine Checkliste brauchen, um den Fokus zu halten, verlinken Sie Ihre Schritte zu einem Runbook wie /blog/performance-incident-workflow, sodass jede neue Metrik einen Zweck hat: eine bestimmte Frage zu beantworten.

Profiling in Produktion, ohne das System herunterzufahren

Produktionsprofiling fühlt sich riskant an, weil es das Live-System berührt — aber es ist oft der schnellste Weg, Debatte durch Beweis zu ersetzen. Logs und Dashboards können sagen, dass etwas langsam ist. Profiling sagt, wo Zeit vergeht: welche Funktionen heißlaufen, welche Threads warten und welche Codepfade während des Vorfalls dominieren.

Was Profiling tatsächlich beantwortet

Profiling ist ein Werkzeug zur „Zeitbudget“-Analyse. Anstatt Theorien zu streiten („es ist die DB“ vs „es ist GC“), erhalten Sie Belege wie „45% der CPU-Samples waren in JSON-Parsen“ oder „die meisten Requests sind auf einem Mutex blockiert“. Das schränkt den nächsten Schritt auf ein oder zwei konkrete Fixes ein.

Häufige Typen, die Sie in Produktion nutzen können

• CPU-Profiling: zeigt, welcher Code on-CPU ausgeführt wird.
• Off-CPU (wait) Profiling: zeigt, wo Threads blockiert sind (I/O-Wartezeit, Scheduler-Delays, Sleep, Netzwerk, Festplatte).
• Lock-Profiling: zeigt Contention — Zeit, die beim Warten auf Sperren, Mutexes und Reader/Writer-Latches verloren geht.

Jeder beantwortet eine andere Frage. Hohe Latenz bei niedriger CPU deutet eher auf off-CPU- oder Lock-Zeit als auf CPU-Hotspots hin.

Always-on vs On-demand

• Always-on Profiling (kontinuierlich, geringer Overhead) hilft bei „es passierte um 3 Uhr morgens“-Mysterien, weil man zurückschauen kann.
• On-demand Profiling ist eine gezielte Aufnahme während eines Spikes. Es ist einfacher einzuführen, aber Sie müssen bereit sein, es schnell auszulösen.

Viele Teams starten on-demand und gehen dann zu always-on über, sobald sie der Sicherheit vertrauen und wiederkehrende Probleme sehen.

Sicherheit: Overhead, Sampling und kurze Fenster

Produktionssicheres Profiling bedeutet Kosten zu kontrollieren. Bevorzugen Sie Sampling (nicht jedes Ereignis verfolgen), halten Sie Aufnahmefenster kurz (z. B. 10–30 Sekunden) und messen Sie den Overhead zuerst in einem Canary. Wenn Sie unsicher sind, starten Sie mit niedriger Sampling-Frequenz und erhöhen Sie nur, wenn das Signal zu verrauscht ist.

Flame-Graphs: wie man sie liest und falsche Schlüsse vermeidet

Flame-Graphs visualisieren, wohin die gesamplete Zeit während eines Profiling-Fensters ging. Jedes „Rechteck“ ist eine Funktion (oder Stack-Frame), und jeder Stack zeigt, wie die Ausführung diese Funktion erreicht hat. Sie sind hervorragend, um Muster schnell zu erkennen — aber sie sagen nicht automatisch „der Bug ist hier“.

Was ein Flame-Graph zeigt (und was nicht)

Ein Flame-Graph repräsentiert in der Regel on-CPU-Samples: Zeit, in der das Programm tatsächlich auf einem CPU-Kern lief. Er kann CPU-intensiven Codepfad, ineffizientes Parsen, übermäßige Serialisierung oder Hotspots hervorheben, die wirklich CPU verbrennen.

Er zeigt aber nicht direkt Wartezeiten auf Festplatte, Netzwerk, Scheduler-Delays oder Blockaden auf einem Mutex (das ist off-CPU-Zeit und benötigt anderes Profiling). Er beweist auch keine Kausalität für nutzerseitige Latenz, es sei denn, Sie verbinden ihn mit einer genau abgegrenzten Symptomatik.

Breite und Stapeltiefe lesen

• Breite: wie oft dieser Frame in den Samples auftauchte. Breiter bedeutet meist „mehr CPU-Zeit“, aber nur innerhalb des gewählten Zeitfensters.
• Stapeltiefe: Call-Tiefe. Tiefe Stacks sind nicht per se schlecht; wichtig ist, welche Pfade dominieren und ob sie zur Arbeit passen, die Sie interessiert.

Häufige Fallen

Die breiteste Box zu beschuldigen ist verlockend, aber fragen Sie: ist das ein Hotspot, den Sie ändern können, oder einfach „Zeit in malloc, GC oder Logging“, weil das eigentliche Problem stromaufwärts liegt? Achten Sie auch auf fehlenden Kontext (JIT, Inlining, Symbole), die ein Rechteck wie den Schuldigen aussehen lassen können, obwohl es nur die Vermittlerfunktion ist.

Kombinieren Sie Flame-Graphs mit einer präzisen Frage

Behandeln Sie einen Flame-Graph als Antwort auf eine eng gefasste Frage: welcher Endpunkt, welches Zeitfenster, welche Hosts und was hat sich geändert. Vergleichen Sie „vorher vs. nachher“ (oder „gesund vs. degradierend“) Flame-Graphs für denselben Request-Pfad, um Profiling-Rauschen zu vermeiden.

Off-CPU-Zeit: die versteckte Quelle von Latenz

Bei Latenzspitzen starren viele Teams zuerst auf CPU%-Werte. Das ist verständlich — aber oft irreführend. Ein Service kann „nur 20% CPU“ nutzen und trotzdem schmerzhaft langsam sein, wenn seine Threads den Großteil ihrer Zeit nicht laufend verbringen.

Warum CPU% allein täuscht

CPU% beantwortet „wie beschäftigt ist der Prozessor?“ Es beantwortet nicht „wo ist meine Request-Zeit geblieben?“ Requests können stillstehen, während Threads warten, blockiert sind oder vom Scheduler geparkt werden.

Eine zentrale Idee: die Wall-Clock-Zeit einer Anfrage umfasst sowohl on-CPU Arbeit als auch off-CPU Wartezeiten.

Häufige Off-CPU-Ursachen

Off-CPU-Zeit verbirgt sich typischerweise hinter Abhängigkeiten und Contention:

• Festplatten-I/O: synchrone Reads/Writes, fsyncs, langsamer Storage, Page-Cache-Misses.
• Netzwerk-Wartezeiten: DNS-Lookups, TCP-Retransmits, überlastete Upstream-Services.
• Sperren und Mutex-Contention: Threads, die auf Sperren, Reader/Writer-Latches, Allokator-Contention warten.
• Queueing: Warteschlangen in Threadpools, Connection-Pools oder internen Work-Queues.

Symptome, die Sie beobachten sollten

Einige Signale korrelieren oft mit Off-CPU-Engpässen:

• steigende Queue-Zeit (Anfragen warten, bevor sie überhaupt mit der Ausführung beginnen)
• zunehmende runnable threads (mehr Wettbewerb um CPU-Zeit)
• erhöhte I/O-Wartezeit und längere Disk-/Netzwerk-Latenzen

Diese Symptome sagen „wir warten“, aber nicht worauf.

Wie Off-CPU-Profiling zeigt, „wo die Zeit hinfloss"

Off-CPU-Profiling schreibt Zeit der Ursache zu, warum Sie nicht liefen: blockiert in Syscalls, wartend auf Sperren, schlafend oder descheduliert. Das ist mächtig für Latenz-Arbeit, weil es vage Verlangsamungen in handhabbare Kategorien verwandelt: „blockiert an Mutex X“, „wartet auf read() von der Festplatte“ oder „steckt in connect() zu einem Upstream“. Sobald Sie den Wartegrund benennen können, können Sie ihn messen, bestätigen und beheben.

Den Engpass mit Beweisen bestätigen, nicht mit Intuition

Performance-Arbeit scheitert oft am selben Punkt: jemand sieht eine verdächtige Metrik, erklärt sie zum „Problem“ und beginnt zu tunen. Greggs Methoden drängen dazu, langsamer zu werden und zu beweisen, was das System limitiert, bevor Sie etwas ändern.

Engpass, Hotspot und Rauschen

Ein Engpass ist die Ressource oder Komponente, die aktuell Throughput begrenzt oder Latenz antreibt. Wenn Sie ihn entlasten, sehen Nutzer eine Verbesserung.

Ein Hotspot ist, wo Zeit verbracht wird (z. B. eine Funktion, die häufig in einem Profil auftaucht). Hotspots können echte Engpässe sein — oder einfach viel Arbeit, die den langsamen Pfad nicht beeinflusst.

Rauschen ist alles, was bedeutungsvoll aussieht, es aber nicht ist: Hintergrundjobs, Einmal-Spikes, Sample-Artefakte, Cache-Effekte oder „Top-Talker“, die nicht mit dem nutzerseitigen Problem korrelieren.

Beweisen Sie es mit Vergleichen und kontrollierten Änderungen

Beginnen Sie mit einer sauberen Before-Momentaufnahme: dem nutzerseitigen Symptom (Latenz oder Fehlerquote) und den führenden Kandidaten-Signalen (CPU-Sättigung, Queuetiefe, Disk-I/O, Sperr-Contention usw.). Dann führen Sie eine kontrollierte Änderung durch, die nur Ihre vermutete Ursache beeinflussen sollte.

Beispiele für kausale Tests:

• Erhöhen Sie Kapazität der verdächtigten Ressource (ein weiterer Worker, mehr CPU-Sharing, größerer Connection-Pool) und prüfen Sie, ob die Latenz besser wird.
• Reduzieren Sie vorübergehend die Last (limitieren Sie einen lauten Endpunkt, spielen Sie eine kleinere Workload) und schauen Sie, ob die vermutete Beschränkung nachlässt.

Korrelation ist ein Hinweis, kein Urteil. Wenn „CPU steigt, wenn Latenz steigt“, verifizieren Sie durch Veränderung der CPU-Verfügbarkeit oder Reduktion der CPU-Arbeit, ob die Latenz folgt.

Dokumentieren Sie, was Sie bewiesen haben

Schreiben Sie auf: was gemessen wurde, die genaue Änderung, Before/After-Ergebnisse und die beobachtete Verbesserung. Das macht einen einmaligen Erfolg zu einem wiederverwendbaren Playbook für den nächsten Vorfall — und verhindert, dass „Intuition“ später die Geschichte umschreibt.

Einen wiederholbaren Workflow für Performance-Vorfälle aufbauen

Performance-Incidents fühlen sich dringlich an — genau dann schleichen sich Raten ein. Ein leichtgewichtiger, wiederholbarer Workflow hilft Ihnen, von „etwas ist langsam“ zu „wir wissen, was sich geändert hat“ zu kommen, ohne Thrash.

Die Incident-Schleife: erkennen → triagieren → messen → beheben

Erkennen: Alarmieren Sie auf nutzerrelevante Latenz und Fehler, nicht nur CPU. Rufen Sie an, wenn p95/p99-Latenz für ein sustainetes Fenster einen Grenzwert überschreitet.

Triagieren: Beantworten Sie sofort drei Fragen: was ist langsam, wann hat es begonnen und wer ist betroffen? Wenn Sie den Scope (Service, Endpoint, Region, Kohorte) nicht benennen können, sind Sie nicht bereit zu optimieren.

Messen: Sammeln Sie Belege, die den Engpass eingrenzen. Bevorzugen Sie zeitlich begrenzte Aufnahmen (z. B. 60–180 Sekunden), damit Sie „schlecht“ vs. „gut“ vergleichen können.

Beheben: Ändern Sie eine Sache nach der anderen und messen Sie dann dieselben Signale erneut, um Verbesserung zu bestätigen und Placebo auszuschließen.

Standardisieren Sie eine kleine Menge an Graphen

Halten Sie ein gemeinsames Dashboard, das jeder während Incidents benutzt. Machen Sie es langweilig und konsistent:

• Latenz: p50 / p95 / p99 (pro kritischem Endpunkt)
• RED-Signale: Rate, Errors, Duration (service-zentrierte Ansicht)
• Einige USE-Metriken: Utilization, Saturation, Errors für CPU, Disk und Netzwerk

Ziel ist nicht, alles zu graphen; es ist, die Time-to-First-Fact zu verkürzen.

Definieren Sie „goldene Signale“ pro kritischem Endpunkt

Instrumentieren Sie die Endpunkte, die am wichtigsten sind (Checkout, Login, Suche), nicht jeden Endpunkt. Vereinbaren Sie für jeden: erwarteter p95, maximale Fehlerquote und Schlüsselabhängigkeit (DB, Cache, Drittanbieter).

Entscheiden Sie, was während Incidents erfasst wird

Vereinbaren Sie vor dem nächsten Ausfall ein Capture-Kit:

• Profile (CPU und Off-CPU) plus Flame-Graphs
• Traces für die langsamen Endpunkte
• Logs für Fehler/Timeouts (gesampelt)

Dokumentieren Sie das in einem kurzen Runbook (z. B. /runbooks/latency), inklusive wer Captures ausführen darf und wo Artefakte abgelegt werden.

Wo Koder.ai in einen Gregg-stiligen Workflow passt

Greggs Methodik dreht sich grundlegend um kontrollierte Änderungen und schnelle Verifikation. Wenn Ihr Team Services mit Koder.ai (einer chat-gesteuerten Plattform zur Generierung und Iteration von Web-, Backend- und Mobile-Apps) baut, passen zwei Features gut zu dieser Denkweise:

• Planning Mode hilft, aus „vielleicht ist es X“ eine explizite Hypothese und eine kleine, testbare Änderungssatz zu machen, bevor man Produktion anfasst.
• Snapshots und Rollback unterstützen sichere, single-variable Experimente: mache eine Änderung, messe RED/USE-Signale erneut und rolle schnell zurück, wenn die Beweise „nein“ sagen.

Auch wenn Sie während eines Incidents keinen neuen Code generieren: diese Gewohnheiten — kleine Diffs, messbare Outcomes und schnelle Umkehrbarkeit — sind dieselben, die Gregg empfiehlt.

Ein praktischer Durchlauf: von Latenzspike zum verifizierten Fix

Das Szenario: p99 springt bei Spitzenlast

Es ist 10:15 Uhr und Ihr Dashboard zeigt, dass die p99-Latenz der API bei Spitzenlast von ~120 ms auf ~900 ms steigt. Die Fehlerquote ist stabil, aber Kunden melden „langsame“ Requests.

Schritt 1 — Beginnen Sie mit RED, um Nutzer-Impact zu finden

Starten Sie service-first: Rate, Errors, Duration.

Sie slice Duration nach Endpunkt und sehen, dass eine Route die p99 dominiert: POST /checkout. Die Rate ist 2× höher, Fehler sind normal, aber die Duration steigt speziell bei erhöhter Concurrency. Das deutet auf Queuing oder Contention hin, nicht auf einen völligen Ausfall.

Prüfen Sie als Nächstes, ob die Latenz Rechenzeit oder Wartezeit ist: vergleichen Sie die Anwendungs-„Handler-Zeit“ mit der Gesamtanfragezeit (oder upstream vs downstream Spans, wenn Tracing vorhanden ist). Die Handler-Zeit ist niedrig, die Gesamtzeit hoch — Anfragen warten.

Schritt 2 — Wenden Sie USE auf die verdächtigen Hosts an

Inventarisieren Sie wahrscheinliche Engpässe: Utilization, Saturation, Errors für CPU, Speicher, Festplatte und Netzwerk.

Die CPU-Auslastung liegt nur bei ~35%, aber Run-Queue und Kontextwechsel steigen. Disk und Netzwerk sehen stabil aus. Diese Diskrepanz (niedrige CPU%, hohe Wartezeiten) ist ein klassischer Hinweis: Threads verbrennen keine CPU — sie sind blockiert.

Schritt 3 — Wählen Sie Profiling basierend auf Symptomen

• Wenn CPU hoch ist: nutzen Sie CPU-Profiling (on-CPU Flame-Graphs), um zu sehen, wo Zeit verbracht wird.
• Wenn Requests warten: nutzen Sie Off-CPU-Profiling, um zu sehen, worauf Threads blockiert sind (Sperren, I/O, Scheduler).

Sie erfassen ein Off-CPU-Profil während des Spikes und finden viel Zeit in einem Mutex um einen geteilten „Promotion-Validation“-Cache.

Schritt 4 — Fix und Verifikation

Sie ersetzen die globale Sperre durch eine Per-Key-Sperre (oder einen lock-freien Read-Pfad), deployen und beobachten, dass p99 wieder auf das Basisniveau sinkt, während die Rate hoch bleibt.

Post-Incident-Checkliste:

• Protokollieren Sie die genauen RED-Symptome und den eingegrenzten Endpunkt.
• Speichern Sie das Profil und das Zeitfenster.
• Fügen Sie einen Alert für das spezifische Saturation-Signal hinzu (z. B. Lock-Wait / Run-Queue).
• Schreiben Sie die „nächste Frage“, die zu stellen ist, falls es erneut passiert.