28 dec. 2025·7 min
Claude Code för prestandautredningar: ett mätbart arbetsflöde
Använd Claude Code för prestandautredningar med en upprepbar loop: mät, formulera en hypotes, ändra lite och mät om innan du levererar.
Använd Claude Code för prestandautredningar med en upprepbar loop: mät, formulera en hypotes, ändra lite och mät om innan du levererar.
Prestandabuggar lockar till gissningar. Någon märker att en sida känns långsam eller att en API-tjänst timear ut, och det snabbaste är att "städa upp" kod, lägga till caching eller skriva om en loop. Problemet är att "känns långsamt" inte är en metrik, och "renare" är inte samma sak som snabbare.
Utan mätning slösar team timmar på att ändra fel sak. Den heta vägen kan vara i databasen, nätverket eller en oväntad enkel allokering, medan teamet polerar kod som nästan aldrig körs. Värre: en förändring som verkar smart kan göra prestandan sämre—extra loggning i en tight loop, en cache som ökar minnespress eller parallellt arbete som skapar lås-konkurrens.
Gissningar riskerar också att bryta beteende. När du ändrar kod för att göra den snabbare kan du påverka resultat, felhantering, ordning eller retries. Om du inte kontrollerar korrekthet och snabbhet tillsammans kan du "vinna" en benchmark samtidigt som du tyst levererar en bugg.
Behandla prestanda som ett experiment, inte en debatt. Loopen är enkel och upprepbar:
Många vinster är modest: skära 8 % från p95-latensen, reducera toppminne med 50 MB eller ta bort en databasfråga. De vinsterna spelar fortfarande roll—men bara om de är mätta, verifierade och upprepbara.
Detta fungerar bäst som en loop, inte ett engångs-"gör det snabbare"-ärende. Loopen håller dig ärlig eftersom varje åtgärd kopplas tillbaka till bevis och ett tal du kan bevaka.
En tydlig sekvens:
Varje steg skyddar mot en annan sorts självbedrägeri. Att mäta först hindrar dig från att "fixa" något som inte var ett verkligt problem. En skriftlig hypotes hindrar dig från att ändra fem saker samtidigt och sedan gissa vilken som spelade roll. Minimala ändringar minskar risken att bryta beteende eller införa nya flaskhalsar. Ommätning fångar placebo-vinster (som en snabbare körning orsakad av varm cache) och blottlägger regressioner.
"Klart" är inte en känsla. Det är ett resultat: målmetrisken rörde sig åt rätt håll och förändringen orsakade inga uppenbara regressioner (fel, mer minne, sämre p95-latens eller långsammare närliggande endpoints).
Att veta när man ska sluta är en del av arbetsflödet. Sluta när vinster planar ut, när metrisken redan är tillräckligt bra för användare, eller när nästa idé kräver stora refaktorer för liten uppsida. Prestandaarbete har alltid alternativkostnad; loopen hjälper dig att lägga tid där det lönar sig.
Om du mäter fem saker på en gång vet du inte vad som förbättrats. Välj en primär metrik för denna undersökning och behandla allt annat som stödjande signaler. För många kundnära problem är den metriska latens. För batchjobb kan det vara throughput, CPU-tid, minnesanvändning eller till och med molnkostnad per körning.
Var specifik om scenariot. "API:t är långsamt" är för vagt. "POST /checkout med en typisk kundvagn på 3 artiklar" är mätbart. Håll indata stabila så att siffrorna betyder något.
Skriv ner baslinjen och miljödetaljerna innan du rör koden: datasetstorlek, maskintyp, build-läge, feature flags, samtidighet och uppvärmning. Denna baslinje är din ankare. Utan den kan varje förändring se ut som framsteg.
För latens, lita på percentiler, inte bara ett medelvärde. p50 visar den typiska upplevelsen, medan p95 och p99 exponerar den smärtsamma svansen som användare klagar över. En förändring som förbättrar p50 men försämrar p99 kan fortfarande kännas långsammare.
Bestäm i förväg vad som är "meningsfullt" så att du inte firar brus:
När dessa regler är satta kan du testa idéer utan att flytta målstolpar.
Börja med den enklaste signalen du kan lita på. En enda timing runt en request kan säga om du har ett verkligt problem och ungefär hur stort det är. Spara djupare profilering tills du behöver förklara varför det är långsamt.
Bra bevis kommer ofta från en blandning av källor:
Använd enkla metriska när frågan är "är det långsammare, och med hur mycket?" Använd profilering när frågan är "vart går tiden?" Om p95-latens fördubblades efter en deploy, börja med timingar och loggar för att bekräfta regressionen och avgränsa den. Om timingar visar att merparten av förseningen är inne i din app-kod (inte DB:n) kan en CPU-profiler eller flame graph peka på exakt vilken funktion som växt.
Håll mätningarna säkra. Samla det du behöver för att debugga prestanda, inte användarinnehåll. Föredra aggregerade värden (durations, counts, sizes) framför råa payloads, och maska identifierare som standard.
Brus är verkligt, så ta flera prover och notera outliers. Kör samma request 10–30 gånger och spela in median och p95 snarare än en enda bästa körning.
Skriv ner exakt testrecept så att du kan upprepa det efter ändringar: miljö, dataset, endpoint, request-body-storlek, samtidighetsnivå och hur du fångade resultaten.
Börja med ett symptom du kan namnge: "p95-latens hoppar från 220 ms till 900 ms under trafiktoppar", "CPU sitter på 95 % på två kärnor" eller "minnet växer med 200 MB per timme." Vaga symptom som "det känns långsamt" leder till slumpmässiga ändringar.
Översätt sedan det du mätte till ett misstänkt område. En flame graph kan visa att mest tid går åt i JSON-serialisering, en trace kan visa en långsam kallkedja, eller databasstatistik kan visa en query som dominerar total tid. Välj det minsta området som förklarar största delen av kostnaden: en funktion, en SQL-fråga eller ett externt anrop.
En bra hypotes är en mening, testbar och knuten till en förutsägelse. Du ber om hjälp att testa en idé, inte att ett verktyg magiskt ska göra allt snabbare.
Använd detta format:
Exempel: "På grund av att profilen visar 38 % av CPU:n i SerializeResponse, och en ny buffer allokeras per request, orsakar det CPU-spikar. Om vi återanvänder en buffer bör p95-latensen sjunka med ungefär 10–20 % och CPU minska med 15 % under samma load."
Håll dig ärlig genom att namnge alternativ innan du rör koden. Kanske är den långsamma delen en upstream-dependency, låskonkurrens, ökade cache-missar eller en rollout som ökade payload-storleken.
Skriv ner 2–3 alternativa förklaringar, och välj sedan den som dina bevis bäst stödjer. Om din ändring inte rör metrisken har du redan nästa hypotes redo.
Claude är mest användbar i prestandaarbete när du behandlar den som en noggrann analytiker, inte ett orakel. Håll varje förslag knutet till vad du mätte, och se till att varje steg kan falsifieras.
Ge den verkliga indata, inte en vag beskrivning. Klistra in små, fokuserade bevis: en profileringssammanfattning, några loggrader kring den långsamma förfrågan, en frågeplan och den specifika kodvägen. Inkludera "före"-siffror (p95-latens, CPU-tid, DB-tid) så att den känner din baslinje.
Be den förklara vad datan tyder på och vad den inte stödjer. Tvinga fram konkurrerande förklaringar. Ett bra promptslut är: "Ge mig 2–3 hypoteser, och för varje, berätta vad som skulle falsifiera den." Det förhindrar att du låser dig vid den första plausibla historien.
Innan du ändrar något, be om det minsta experimentet som kan validera ledande hypotes. Håll det snabbt och reversibelt: lägg till en timer runt en funktion, slå på en profiler-flagga eller kör en DB-fråga med EXPLAIN.
Om du vill ha en strikt struktur i svaret, be om:
Om den inte kan namnge en specifik metrik, plats och förväntat resultat är du tillbaka i gissningsläget.
När du har bevis och en hypotes, motstå frestelsen att "städa upp allt." Prestandaarbete är lättast att lita på när kodändringen är liten och lätt att ångra.
Ändra en sak i taget. Om du tweakar en query, lägger till caching och refaktorerar en loop i samma commit vet du inte vad som hjälpte (eller skadade). Envariabel-ändringar gör nästa mätning meningsfull.
Skriv innan du rör koden ner vad du förväntar dig i siffror. Exempel: "p95-latens bör gå från 420 ms till under 300 ms, och DB-tiden bör sjunka med cirka 100 ms." Om resultatet inte når det målet lär du dig snabbt att hypotesen var svag eller ofullständig.
Håll ändringar reversibla:
"Minimal" betyder inte "trivial." Det betyder fokuserad: cachea en dyr funktion, ta bort en upprepad allokering i en tight loop eller sluta göra arbete för requests som inte behöver det.
Lägg till lättviktig timing runt den misstänkta flaskhalsen så att du ser vad som rörde sig. Ett enda tidsstempel före och efter ett anrop (loggat eller fångat som en metrik) kan bekräfta om din ändring träffade den långsamma delen eller bara flyttade tiden någon annanstans.
Efter en ändring, kör om exakt samma scenario du använde för baslinjen: samma indata, miljö och lastprofil. Om ditt test beror på caches eller uppvärmning, specificera det (t.ex. "första körningen kall, nästa 5 varma"). Annars kommer du att "hitta" förbättringar som bara var tur.
Jämför resultat med samma metrik och samma percentiler. Medelvärden kan dölja smärta, så håll koll på p95 och p99-latens, plus throughput och CPU-tid. Kör tillräckligt många repetitioner för att se om siffrorna stabiliseras.
Innan du firar, kontrollera regressioner som inte syns i en huvudmetrik:
Då beslutar du baserat på bevis, inte hopp. Om förbättringen är verklig och du inte introducerade regressioner, behåll den. Om resultaten är mixade eller bullriga, återställ och formulera en ny hypotes, eller isolera ändringen ännu mer.
Om du jobbar i en plattform som Koder.ai kan en snapshot före experiment göra rollback till ett steg, vilket gör det enklare att testa djärva idéer säkert.
Skriv slutligen ner vad du lärde dig: baslinjen, ändringen, de nya siffrorna och slutsatsen. Denna korta anteckning hindrar nästa runda från att upprepa samma blindgångar.
Prestandaarbete går oftast åt skogen när du tappar tråden mellan vad du mätte och vad du ändrade. Håll en ren kedja av bevis så att du säkert kan säga vad som gjorde saker bättre eller sämre.
De återkommande felen:
Ett litet exempel: en endpoint ser långsam ut, så du optimerar serialisering eftersom den är het i en profil. Sedan kör du om med ett mindre dataset och det ser snabbare ut. I produktion blir p99 sämre eftersom databasen fortfarande var flaskhalsen och din ändring ökade payload-storleken.
Om du använder Claude Code för att föreslå fixar, håll den i kort koppel. Be om 1–2 minimala ändringar som matchar de bevis du redan samlat och insistera på en ommätningsplan innan du accepterar en patch.
Hastighetsanspråk faller när testet är otydligt. Innan du firar, se till att du kan förklara vad du mätte, hur du mätte det och vad du ändrade.
Börja med att namnge en metrik och skriva ner baslinjeresultatet. Inkludera detaljer som ändrar siffror: maskintyp, CPU-belastning, datasetstorlek, build-läge (debug vs release), feature flags, cachestatus och samtidighet. Om du inte kan återskapa uppsättningen imorgon har du ingen baslinje.
Checklista:
När siffrorna ser bättre ut, gör en snabb regressionspass. Kontrollera korrekthet (samma utdata), felrate och timeouts. Bevaka sidoeffekter som högre minne, CPU-spikar, långsammare uppstart eller mer DB-belastning. En ändring som förbättrar p95 men fördubblar minnet kan vara fel trade-off.
Ett team rapporterar att GET /orders känns bra i dev men blir långsamt i staging vid måttlig load. Användare klagar på timeouts, men medelvärdet ser fortfarande "okej" ut—det är en klassisk fälla.
Först, sätt en baslinje. Under ett stabilt load-test (samma dataset, samma samtidighet, samma längd) registrerar du:
Saml bevis. Ett snabbt trace visar att endpointen kör en huvudquery för orders och sedan loopar och fetchar relaterade items per order. Du noterar också att JSON-responsen är stor, men DB-tid dominerar.
Gör det till en hypoteslista du kan testa:
Begär en minimal ändring som matchar starkaste beviset: ta bort en uppenbar N+1-genom att hämta items i en enda query nycklad på order-IDs (eller lägg till saknade index om query-planen visar full scan). Håll det reversibelt och i en fokuserad commit.
Mät om med samma load-test. Resultat:
Beslut: släpp fixen (klart win), och starta sedan en andra cykel fokuserad på återstående gap och CPU-spikar, eftersom DB inte längre är huvudsaklig begränsare.
Det snabbaste sättet att bli bättre på prestandautredningar är att behandla varje körning som ett litet experiment du kan upprepa. När processen är konsekvent blir resultaten lättare att lita på, jämföra och dela.
En enkel en-sida-mall hjälper:
Bestäm var dessa anteckningar lever så att de inte försvinner. En delad plats betyder mer än det perfekta verktyget: en mapp i repo:t bredvid tjänsten, ett team-dokument eller ticket-noter. Nyckeln är upptäckbarhet. Någon ska kunna hitta "p95-latensspik efter caching-ändring" månader senare.
Gör säkra experiment till vana. Använd snapshots och enkel rollback så att du kan prova en idé utan rädsla. Om du bygger med Koder.ai kan Planning Mode vara en bekväm plats att skissa mätplanen, definiera hypotesen och hålla ändringen begränsad innan du genererar en tight diff och mäter om.
Sätt en rutin. Vänta inte på incidenter. Lägg till små prestandakontroller efter ändringar som nya queries, nya endpoints, större payloads eller beroendeuppgraderingar. En 10-minuters baslinjekontroll nu kan spara en dag av gissande senare.
Börja med ett tal som matchar klagomålet, vanligtvis p95-latens för en specifik endpoint och indata. Registrera en baslinje under samma förhållanden (datastorlek, samtidighet, varm/kall cache), ändra sedan en sak och mät igen.
Om du inte kan reproducera baslinjen så mäter du inte än—du gissar.
En bra baslinje innehåller:
Skriv ner det innan du rör koden så att du inte flyttar målstrecket.
Percentiler visar användarupplevelsen bättre än ett medelvärde. p50 är ”typiskt”, men användare klagar över långsvansen som är p95/p99.
Om p50 blir bättre men p99 blir sämre kan systemet ändå kännas långsammare även om genomsnittet ser bättre ut.
Använd enkla timingar/loggar när du frågar ”är det långsammare och med hur mycket?” Använd profilering när du frågar ”vart går tiden?”
En praktisk ordning är: bekräfta regressionen med request-timing, och profilera först när du vet att slowdownen är verklig och avgränsad.
Välj en primär metrik och behandla resten som skyddssignaler. Ett vanligt set är:
Det hindrar dig från att ”vinna” en graf medan du tyst orsakar timeouts, minnesläckor eller värre tail-latency.
Skriv en en-sats-hypotes knuten till bevis och en förutsägelse:
Om du inte kan namnge beviset och den förväntade metriska rörelsen är hypotesen inte testbar än.
Gör den liten, fokuserad och enkel att ångra:
Små diffar gör nästa mätning meningsfull och minskar risken att du bryter funktionalitet medan du jagar hastighet.
Kör om exakt samma scenario du använde för baslinjen: samma indata, miljö och lastprofil. Om testet kräver cache- eller uppvärmningsregler, var tydlig (t.ex. "första körningen kall, nästa 5 är varma"). Annars hittar du förbättringar som bara var tur.
Jämför med samma metriska och samma percentiler. Kontrollera även för regressionsproblem:
Ge Claude verkliga indata, inte en vag beskrivning. Klistra in små, fokuserade bevis: en profileringssammanfattning, några loggrader kring den långsamma förfrågan, en frågeplan och den specifika kodvägen. Inkludera "före"-siffror (p95, CPU-tid, DB-tid) så att den vet din baslinje.
Be den förklara vad datan tyder på och vad den inte stödjer. Tvinga fram konkurrerande förklaringar. Ett användbart promptslut är: "Ge mig 2–3 hypoteser, och för varje, berätta vad som skulle falsifiera den." Det förhindrar att man låser sig vid den första rimliga förklaringen.
Sluta när:
Prestandaarbete har alltid alternativkostnad. Loopen (mät → hypotes → ändra → mät om) hjälper dig att lägga tid där siffrorna visar att det lönar sig.
Om förbättringen är verklig och inga uppenbara regressioner introducerades, behåll den. Om det är bullrigt eller mixat, revert och forma en ny hypotes eller isolera ändringen mer.