Claude Code für Performance-Untersuchungen: ein gemessener Workflow

Warum Performance-Arbeit ohne Messen schiefgeht

Performance-Bugs laden zum Raten ein. Jemand merkt, dass eine Seite sich langsam anfühlt oder eine API timeouts hat, und der schnellste Reflex ist, Code zu „bereinigen“, Caching hinzuzufügen oder eine Schleife umzuschreiben. Das Problem: „fühlt sich langsam an" ist keine Metrik, und „sauberer" ist nicht gleich schneller.

Ohne Messung verbrauchen Teams Stunden, um am falschen Ort Änderungen vorzunehmen. Der heiße Pfad kann in der Datenbank, im Netzwerk oder in einer unerwarteten Allokation liegen, während das Team Code poliert, der kaum zur Laufzeit beiträgt. Schlimmer noch: eine Änderung, die schlau aussieht, kann die Performance verschlechtern — extra Logging in einer engen Schleife, ein Cache, der den Speicherdruck erhöht, oder Parallelisierung, die Lock-Contention erzeugt.

Raten gefährdet auch die Korrektheit. Wenn du Code änderst, um ihn zu beschleunigen, kannst du Ergebnisse, Fehlerbehandlung, Reihenfolge oder Retries verändern. Wenn du Korrektheit und Geschwindigkeit nicht zusammen erneut prüfst, kannst du in einem Benchmark „gewinnen“ und gleichzeitig einen Bug ausliefern.

Behandle Performance wie ein Experiment, nicht wie eine Debatte. Die Schleife ist einfach und wiederholbar:

• Wähle eine Metrik, die den Schmerz repräsentiert (Latenz, Durchsatz, CPU, Speicher, DB-Zeit).
• Erfasse eine Basislinie unter gleichen Bedingungen.
• Ändere eine kleine Sache.
• Messe erneut und vergleiche.

Viele Verbesserungen sind moderat: 8 % p95-Latenz sparen, 50 MB Peak-Speicher reduzieren oder eine Datenbankabfrage entfernen. Diese Gewinne zählen — aber nur, wenn sie gemessen, verifiziert und reproduzierbar sind.

Der Workflow: messen, hypothesieren, ändern, neu messen

Das funktioniert am besten als Schleife, nicht als einmalige „mach schneller“-Anfrage. Die Schleife hält dich ehrlich, weil jede Aktion zu einem Beweis und einer Zahl zurückführt, die du beobachten kannst.

Eine klare Reihenfolge:

• Messen: Wähle eine Metrik und dokumentiere eine Basislinie.
• Hypothese: Erkläre, was deiner Meinung nach langsam ist und warum.
• Ändern: Mache die kleinstmögliche Anpassung, die die Hypothese testet.
• Neu messen: Führe die gleiche Messung erneut aus und vergleiche.

Jeder Schritt schützt vor einer anderen Art Selbsttäuschung. Erst messen verhindert, dass du etwas „behebst“, das kein echtes Problem war. Eine geschriebene Hypothese hindert dich daran, fünf Dinge auf einmal zu ändern und dann zu raten, was geholfen hat. Minimale Änderungen reduzieren das Risiko, Verhalten zu brechen oder neue Engpässe einzuführen. Neu messen fängt Placebo-Effekte ein (z. B. schnellerer Lauf wegen warmem Cache) und deckt Regressionsprobleme auf.

„Fertig" ist kein Gefühl. Es ist ein Ergebnis: die Zielmetrik hat sich in die richtige Richtung bewegt, und die Änderung hat keine offensichtlichen Regressionen verursacht (Fehler, mehr Speicher, schlechteres p95, langsamere nahegelegene Endpoints).

Zu wissen, wann man aufhört, gehört zum Workflow. Hör auf, wenn die Gewinne abflachen, die Metrik für Nutzer gut genug ist oder die nächste Idee großen Refactor-Aufwand für wenig Nutzen verlangt. Performance-Arbeit hat immer Opportunitätskosten; die Schleife hilft dir, Zeit dort auszugeben, wo es sich lohnt.

Wähle die Metrik und setze eine Basislinie

Wenn du fünf Dinge gleichzeitig misst, weißt du am Ende nicht, was sich verbessert hat. Wähle eine primäre Metrik für die Untersuchung und behandle alles andere als unterstützende Signale. Für viele nutzerorientierte Probleme ist das die Latenz. Für Batch-Arbeit kann es Durchsatz, CPU-Zeit, Speicher oder sogar Kosten pro Lauf sein.

Sei spezifisch beim Szenario. "Die API ist langsam" ist zu vage. "POST /checkout mit einem typischen Warenkorb von 3 Artikeln" ist messbar. Halte die Inputs stabil, damit die Zahlen etwas bedeuten.

Schreibe die Basislinie und Umgebungsdetails auf, bevor du Code änderst: Datensatzgröße, Maschinentyp, Build-Modus, Feature-Flags, Konkurrenz und Aufwärmzustand. Diese Basislinie ist dein Anker. Ohne sie kann jede Änderung wie Fortschritt aussehen.

Bei Latenz verlasse dich auf Perzentile, nicht nur auf den Mittelwert. p50 zeigt das typische Erlebnis, während p95 und p99 die schmerzhaften Ausreißer offenbaren, über die Nutzer klagen. Eine Änderung, die p50 verbessert, aber p99 verschlechtert, kann sich trotzdem langsamer anfühlen.

Entscheide vorab, was „bedeutend" bedeutet, damit du kein Rauschen feierst:

• Latenz: mindestens 10 % Verbesserung bei p95 (oder ein fester Schwellenwert wie 50 ms)
• Durchsatz: mindestens 5 % mehr Requests pro Sekunde bei gleicher Fehlerrate
• CPU oder Speicher: genug Reduktion, um Skalierung oder Abstürze zu vermeiden
• Kosten: messbare Senkung pro Lauf oder pro 1.000 Requests

Sind diese Regeln festgelegt, kannst du Ideen testen, ohne die Zielpfosten zu verschieben.

Sammle Beweise mit Profiling und einfachen Metriken

Fange mit dem einfachsten Signal an, dem du vertraust. Ein einzelnes Timing um eine Anfrage herum kann dir sagen, ob du ein echtes Problem hast und wie groß es ungefähr ist. Tieferes Profiling nutzt du, wenn du erklären musst, warum etwas langsam ist.

Gute Beweise kommen oft aus einer Mischung von Quellen:

• App-Logs (Request-Dauer, Fehlerrate, langsamste Endpoints)
• APM-Traces (wo Zeit über Services hinweg verbracht wird)
• Profiler-Ausgaben oder Flame-Graphs (heiße Funktionen und Call-Stacks)
• Datenbank-Statistiken (langsame Queries, Lock-Waits, Cache-Hit-Rate)
• Infrastruktur-Metriken (CPU, Speicher, Netzwerk, Container-Restarts)

Nutze einfache Metriken, wenn die Frage lautet „ist es langsamer und um wie viel?" Profiling ist sinnvoll, wenn die Frage lautet „wo geht die Zeit hin?" Wenn die p95-Latenz nach einem Deploy verdoppelt, beginne mit Timings und Logs, um die Regression zu bestätigen und einzugrenzen. Wenn Timings zeigen, dass der Großteil der Verzögerung in deinem App-Code liegt (nicht in der DB), kann ein CPU-Profiler oder ein Flame-Graph die genaue Funktion zeigen, die gewachsen ist.

Halte Messungen sicher. Sammle, was du zum Debuggen brauchst, nicht Nutzerinhalte. Bevorzuge Aggregate (Dauern, Zählungen, Größen) statt roher Payloads und redactiere IDs standardmäßig.

Rauschen ist real — nimm mehrere Samples und notiere Ausreißer. Führe dieselbe Anfrage 10–30 Mal aus und zeichne Median und p95 statt eines einzelnen besten Laufs auf.

Schreibe das genaue Testrezept auf, damit du es nach Änderungen wiederholen kannst: Umgebung, Datensatz, Endpoint, Request-Body-Größe, Konkurrenzlevel und wie du die Ergebnisse erfasst hast.

Verwandle Beweise in eine klare Hypothese

Beginne mit einem benennbaren Symptom: "p95-Latenz springt von 220 ms auf 900 ms bei Traffic-Spitzen", "CPU liegt bei 95 % auf zwei Kernen" oder "Speicher wächst um 200 MB pro Stunde." Vage Symptome wie "es fühlt sich langsam an" führen zu zufälligen Änderungen.

Übersetze dann das Gemessene in einen verdächtigen Bereich. Ein Flame-Graph kann zeigen, dass viel Zeit im JSON-Encoding liegt, ein Trace kann einen langsamen Call-Path zeigen, oder DB-Statistiken können eine Query offenbaren, die die Gesamtzeit dominiert. Wähle den kleinsten Bereich, der den Großteil der Kosten erklärt: eine Funktion, eine einzelne SQL-Abfrage oder einen externen Call.

Eine gute Hypothese ist ein Satz, testbar und mit einer Vorhersage verknüpft. Du bittest um Hilfe, eine Idee zu testen — nicht darum, dass ein Tool alles magisch schneller macht.

Ein einfaches Hypothesen-Template

Verwende dieses Format:

• Wegen (Beweis) verursacht (Verdächtiger) (Symptom).
• Wenn wir (konkretes Verhalten) ändern, sollte (Metrik) sich um (ungefähre Größe) verbessern.
• Wir wissen, dass es funktioniert hat, wenn (Ergebnis der Neu-Messung).

Beispiel: "Weil das Profil zeigt, dass 38 % der CPU in SerializeResponse liegen, verursacht das Anlegen eines neuen Puffers pro Request CPU-Spitzen. Wenn wir einen Puffer wiederverwenden, sollte die p95-Latenz um etwa 10–20 % sinken und die CPU unter gleicher Last um ~15 % fallen."

Halte dich ehrlich, indem du Alternativen benennst, bevor du Code änderst. Vielleicht liegt das Problem tatsächlich upstream, an Lock-Contention, einer Änderung der Cache-Miss-Rate oder an einem Rollout, das die Payload-Größe erhöht hat.

Schreibe 2–3 alternative Erklärungen auf und wähle dann diejenige, die deine Beweise am besten stützt. Wenn deine Änderung die Metrik nicht bewegt, hast du bereits die nächste Hypothese parat.

Wie du Claude Code nutzt, ohne ins Raten abzudriften

Claude ist bei Performance-Arbeit am nützlichsten, wenn du ihn wie einen sorgfältigen Analysten behandelst, nicht wie ein Orakel. Halte jede Empfehlung an das Gebot gebunden, was du gemessen hast, und sorge dafür, dass jeder Schritt widerlegbar ist.

Gib ihm echte Inputs, keine vage Beschreibung. Füge kleine, fokussierte Beweise ein: eine Profil-Zusammenfassung, ein paar Log-Zeilen um die langsame Anfrage, einen Query-Plan und den konkreten Code-Pfad. Beilagen sollten auch "Vorher"-Zahlen enthalten (p95-Latenz, CPU-Zeit, DB-Zeit), damit die Ausgangslage klar ist.

Bitte es, zu erklären, was die Daten nahelegen und was nicht. Fordere konkurrierende Erklärungen. Ein hilfreicher Prompt endet mit: "Gib mir 2–3 Hypothesen, und für jede nenne, wie man sie falsifizieren kann." Das verhindert, dass man sich an die erstbeste plausible Erklärung klammert.

Bevor du irgendetwas änderst, bitte um das kleinste Experiment, das die führende Hypothese validiert. Halte es schnell und umkehrbar: eine Timer-Messung um eine Funktion, eine Profiler-Flag setzen oder eine DB-Abfrage mit EXPLAIN laufen lassen.

Wenn du eine strikte Struktur für die Ausgabe willst, fordere:

• Was die Beweise anzeigen (und wie sicher)
• 2–3 Hypothesen mit einem Falsifikationstest
• Die kleinste Code- oder Config-Änderung, um die Top-Hypothese zu testen
• Genau welche Metrik neu gemessen werden soll und in welche Richtung

Wenn es keine spezifische Metrik, keinen Ort und kein erwartetes Ergebnis benennt, bist du wieder beim Raten.

Mache minimale, reversible Änderungen

Hast du Beweise und eine Hypothese, widerstehe dem Drang, "alles aufzuräumen." Performance-Arbeit ist am einfachsten vertrauenswürdig, wenn die Codeänderung klein und leicht rückgängig zu machen ist.

Ändere eine Sache auf einmal. Wenn du eine Query anpasst, Caching hinzufügst und eine Schleife refaktorierst, weißt du nicht, was geholfen hat (oder geschadet). Einfaktor-Änderungen machen die nächste Messung aussagekräftig.

Schreibe vor der Änderung auf, was du in Zahlen erwartest. Beispiel: "p95-Latenz sollte von 420 ms auf unter 300 ms fallen, und DB-Zeit sollte um ~100 ms sinken." Wenn das Ziel verfehlt wird, lernst du schnell, dass die Hypothese schwach oder unvollständig war.

Halt die Änderungen reversibel:

• Bevorzuge kleine Diffs, die sauber revertierbar sind.
• Setze die Änderung hinter eine einfache Flag, damit du sie schnell ausschalten kannst.
• Vermeide Drive-by-Refactors, die Namen, Formatierung und Logik gleichzeitig ändern.
• Begrenze den Scope: ein Endpoint, ein Hot Path, ein teurer Aufruf.
• Füge eine kurze Notiz in die Commit-Nachricht mit erwarteten Vorher/Nachher-Metriken.

"Minimal" heißt nicht „trivially“. Es bedeutet fokussiert: cachiere ein teures Funktionsresultat, entferne eine wiederholte Allokation in einer engen Schleife oder unterlasse Arbeit für Requests, die sie nicht brauchen.

Füge leichte Timings um den vermuteten Engpass hinzu, damit du siehst, was sich bewegt hat. Ein Timestamp vor und nach einem Aufruf (geloggt oder als Metrik erfasst) kann bestätigen, ob deine Änderung das langsame Stück getroffen hat oder die Zeit nur verschoben wurde.

Neu messen und entscheiden, wie es weitergeht

Nach einer Änderung führe exakt dasselbe Szenario aus, das du für die Basislinie verwendet hast: gleiche Inputs, gleiche Umgebung und gleiche Lastform. Wenn dein Test Caches oder Aufwärmen benötigt, mache das explizit (z. B.: "erster Lauf kalt, nächste 5 Läufe warm"). Sonst „entdeckst“ du Verbesserungen, die nur Glück waren.

Vergleiche Ergebnisse mit derselben Metrik und denselben Perzentilen. Mittelwerte können Schmerzen verbergen — beobachte p95 und p99, plus Durchsatz und CPU-Zeit. Führe genug Wiederholungen durch, um zu sehen, ob sich die Zahlen einpendeln.

Bevor du feierst, prüfe auf Regressionsarten, die nicht in der Schlagzeile stehen:

• Korrektheit: Antworten entsprechen weiterhin der Erwartung.
• Fehlerrate: Timeouts, 5xx, Retries.
• Speicher: höherer Peak oder stetiges Wachstum über Läufe.
• Tail-Latenz: p99 wurde schlechter, obwohl p50 besser wurde.
• Ressourcenkosten: CPU- oder DB-Last ist hochgesprungen.

Dann entscheide auf Basis der Beweise, nicht der Hoffnung. Wenn die Verbesserung echt ist und du keine Regressionen eingeführt hast, behalte die Änderung. Wenn die Ergebnisse gemischt oder verrauscht sind, revertiere und formuliere eine neue Hypothese oder isoliert die Änderung weiter.

Wenn du auf einer Plattform wie Koder.ai arbeitest, kann ein Snapshot vor dem Experiment die Rücksetzung zu einem Schritt machen, was mutigere Tests sicherer macht.

Schreibe schließlich auf, was du gelernt hast: Basislinie, Änderung, neue Zahlen und Fazit. Diese kurze Aufzeichnung verhindert, dass die nächste Runde dieselben Sackgassen wiederholt.

Häufige Fehler, die Zeit kosten

Performance-Arbeit gerät meist aus dem Ruder, wenn die Verbindung zwischen dem, was du gemessen hast, und dem, was du geändert hast, verloren geht. Halte eine saubere Beweiskette, damit du mit Gewissheit sagen kannst, was Dinge besser oder schlechter gemacht hat.

Die üblichen Fehler:

• Das falsche Ziel reparieren: du feierst ein schnelleres Mittel (p50), aber die Tail-Latenz (p95/p99) bleibt schlecht.
• Viele Änderungen auf einmal: Refactors, Caching und Query-Änderungen in einem Commit — du weißt nicht, was geholfen hat.
• Einer verrauschten Messung glauben: ein lokales Benchmark, das 20 % zwischen Läufen schwankt, ist kein Beweis.
• Ein Profil als alle Wahrheit ansehen: ein Flame-Graph zeigt JSON-Parsing, aber Anfragen stauen sich wegen DB-Verzögerungen.
• Äpfel mit Birnen vergleichen: unterschiedliche Datensätze, Feature-Flags, Hardware oder Konkurrenzlevel und trotzdem Schlussfolgerungen ziehen.

Ein kleines Beispiel: Ein Endpoint wirkt langsam, also optimierst du den Serializer, weil er im Profil heiß aussieht. Beim Retest benutzt du jedoch einen kleineren Datensatz — es sieht schneller aus. In Produktion verschlechtert sich p99, weil die Datenbank weiter der Engpass ist und deine Änderung die Payload-Größe erhöht hat.

Wenn du Claude Code um Vorschläge bittest, halte die Zügel kurz. Fordere 1–2 minimale Änderungen, die zu den bereits gesammelten Beweisen passen, und bestehe auf einem Re-Measure-Plan, bevor du einen Patch akzeptierst.

Eine schnelle Checkliste, bevor du „schneller" sagst

Geschwindigkeitsansprüche zerfallen, wenn der Test verschwommen ist. Bevor du feierst, stelle sicher, dass du erklären kannst, was du gemessen hast, wie du es gemessen hast und was du geändert hast.

Beginne damit, eine Metrik zu benennen und die Basislinie mit Umgebungsangaben aufzuschreiben (Hardware, Konfiguration, Daten, Build-Modus, Feature-Flags, Cache-Status, Konkurrenz). Wenn du das Setup morgen nicht reproduzieren kannst, hast du keine Basislinie.

Checkliste:

• Metrik und Basislinie sind mit Umgebungsnotizen aufgezeichnet (Hardware, Config, Daten, warm/kalt).
• Testschritte sind notiert und wiederholbar.
• Du hast eine Hypothese mit einer Vorhersage (z. B. „Wenn wir N+1-Queries entfernen, sollte p95 um ~30 % fallen").
• Du hast eine kleine, reversible Änderung gemacht und genau dokumentiert, was sich bewegt hat (Datei, Funktion, Query, Einstellung).
• Du hast mehrfach nachgemessen und gleiche mit gleichen verglichen (gleiche Inputs, gleiche Last).

Wenn die Zahlen besser aussehen, mache einen schnellen Regressions-Check. Prüfe Korrektheit (gleiche Outputs), Fehlerrate und Timeouts. Achte auf Nebeneffekte wie höheren Speicher, CPU-Spitzen, langsameren Startup oder mehr DB-Last. Eine Änderung, die p95 verbessert, aber den Speicher verdoppelt, ist vielleicht das falsche Tauschverhältnis.

Beispiel: Untersuchung eines langsamen API-Endpoints Schritt für Schritt

Ein Team meldet, dass GET /orders in Dev okay wirkt, aber in Staging bei moderater Last langsamer wird. Nutzer klagen über Timeouts, während die durchschnittliche Latenz noch „ok" aussieht — eine klassische Falle.

Zuerst die Basislinie: Unter einem stabilen Lasttest (gleicher Datensatz, gleiche Konkurrenz, gleiche Dauer) misst du:

• p95-Latenz: 1,8 s (Ziel < 600 ms)
• API-CPU: ~70 % mit gelegentlichen Spitzen
• DB: eine Query dauert 900–1100 ms, und die gesamte Query-Zeit pro Request liegt bei ~1,3 s

Sammle Beweise. Ein schneller Trace zeigt, dass der Endpoint eine Hauptquery für Bestellungen ausführt und dann pro Bestellung verwandte Items einzeln abfragt. Die JSON-Antwort ist groß, aber die DB-Zeit dominiert.

Formuliere eine prüfbare Hypothesenliste:

• Eine langsame Query braucht einen Index.
• N+1-Queries multiplizieren die DB-Zeit.
• Die Serialisierung ist langsam wegen großer Payloads.
• Lock-Contention blockiert Lesezugriffe bei Schreibvorgängen.

Bitte um eine minimale Änderung, die zur stärksten Evidenz passt: entferne eine offensichtliche N+1-Call-Quelle, indem du Items in einer einzigen Query per Order-IDs holst (oder füge den fehlenden Index hinzu, wenn der Query-Plan einen Full-Scan zeigt). Halte es revertierbar und in einem fokussierten Commit.

Messe mit demselben Lasttest neu. Ergebnisse:

• p95-Latenz: 1,8 s → 720 ms
• Gesamte DB-Zeit: ~1,3 s → ~420 ms
• CPU: etwas niedriger, aber weiterhin spiky

Entscheidung: Fix ausliefern (klarer Gewinn), dann eine zweite Runde starten, die sich auf die verbleibende Lücke und die CPU-Spitzen konzentriert, da DB nicht mehr der Hauptlimitierer ist.

Nächste Schritte: mach diesen Workflow zur Routine

Der schnellste Weg, besser bei Performance-Untersuchungen zu werden, ist, jeden Durchlauf wie ein kleines, wiederholbares Experiment zu behandeln. Wenn der Prozess konsistent ist, werden Ergebnisse leichter vertrauenswürdig, vergleichbar und teilbar.

Eine einfache einseitige Vorlage hilft:

• Metrik + wie sie gemessen wird (Tool, Befehl, Datensatz)
• Basislinie (Zahlen, Umgebung, Zeitpunkt)
• Hypothese (ein Satz, testbar)
• Änderung (kleiner Diff, was du berührt hast)
• Ergebnis (Vorher/Nachher + Entscheidung)

Entscheide, wo diese Notizen leben, damit sie nicht verschwinden. Ein gemeinsamer Ort ist wichtiger als das perfekte Tool: ein Repo-Ordner neben dem Service, ein Team-Dokument oder Ticket-Notizen. Wichtig ist Auffindbarkeit. Jemand sollte "p95-Latenz-Anstieg nach Caching-Änderung" noch Monate später finden können.

Mache sichere Experimente zur Gewohnheit. Nutze Snapshots und einfache Rollbacks, damit du Ideen ohne Angst testen kannst. Wenn du mit Koder.ai baust, kann Planning Mode ein praktischer Ort sein, um den Messplan zu skizzieren, die Hypothese zu definieren und die Änderung zu begrenzen, bevor du einen engen Diff generierst und neu misst.

Setze eine Cadenz. Warte nicht auf Vorfälle. Füge nach Änderungen wie neuen Queries, Endpoints, größeren Payloads oder Dependency-Upgrades kleine Performance-Checks hinzu. Ein 10-minütiger Baseline-Check jetzt kann einen Tag Rätselraten später sparen.