Claude Code do badań wydajności: mierzalny przepływ pracy

Dlaczego prace nad wydajnością idą źle bez pomiaru

Błędy wydajnościowe zachęcają do zgadywania. Ktoś zauważa, że strona wydaje się wolna albo API time'uje, a najszybszym ruchem jest „posprzątanie” kodu, dodanie cache'u lub przerobienie pętli. Problem w tym, że „wydaje się wolne” to nie metryka, a „czyściej” nie znaczy „szybciej”.

Bez pomiaru zespoły tracą godziny na zmiany w złym miejscu. Gorąca ścieżka może być w bazie danych, w sieci albo w jednym nieoczekiwanym przydziale pamięci, podczas gdy zespół poleruje kod, który i tak rzadko się uruchamia. Co gorsza, zmiana, która wygląda sprytnie, może pogorszyć wydajność: dodatkowe logowanie w ciasnej pętli, cache zwiększający presję pamięci albo równoległa praca tworząca blokadę.

Zgadywanie też grozi złamaniem działania. Gdy zmieniasz kod, żeby przyspieszyć, możesz zmienić wyniki, obsługę błędów, kolejność lub retry. Jeśli nie sprawdzisz poprawności i wydajności razem, możesz „wygrać” benchmark, jednocześnie wysyłając błąd do produkcji.

Traktuj pracę nad wydajnością jak eksperyment, nie jak spór. Pętla jest prosta i powtarzalna:

• Wybierz jedną metrykę reprezentującą problem (latencja, przepustowość, CPU, pamięć, czas DB).
• Zrób baseline w tych samych warunkach.
• Zmień jedną, małą rzecz.
• Zmierz ponownie i porównaj.

Wiele zwycięstw jest skromnych: 8% mniej na p95, 50 MB mniej w piku pamięci albo usunięcie jednego zapytania do DB. Te zwycięstwa mają znaczenie, ale tylko jeśli są zmierzone, zweryfikowane i powtarzalne.

Workflow: mierzyć, hipotezować, zmieniać, mierzyć ponownie

To działa najlepiej jako pętla, nie jednorazowe „przyspiesz to” żądanie. Pętla trzyma cię w ryzach, bo każda akcja odwołuje się do dowodu i liczby, którą możesz obserwować.

Jasna sekwencja:

• Mierz: wybierz jedną metrykę i zapisz baseline.
• Hipoteza: wyjaśnij, co twoim zdaniem jest wolne i dlaczego.
• Zmiana: wprowadź najmniejszą możliwą modyfikację testującą hipotezę.
• Mierz ponownie: uruchom ten sam pomiar i porównaj.

Każdy krok chroni przed innym rodzajem oszustwa wobec siebie. Pomiar na początku powstrzymuje przed „naprawianiem” czegoś, co nie było prawdziwym problemem. Pisemna hipoteza powstrzymuje przed zmianą pięciu rzeczy naraz i zgadywaniem, która miała wpływ. Minimalne zmiany zmniejszają ryzyko złamania zachowania albo dodania nowych wąskich gardeł. Ponowny pomiar wykrywa placebo (np. szybszy przebieg spowodowany rozgrzanym cache'em) i ujawnia regresje.

„Gotowe” to nie uczucie. To wynik: docelowa metryka poszła w dobrym kierunku, a zmiana nie spowodowała oczywistych regresji (błędy, większa pamięć, gorsze p95 albo wolniejsze sąsiednie endpointy).

Wiedza, kiedy przestać, jest częścią workflow. Przestań, gdy zyski się wypłaszczają, metryka jest już wystarczająca dla użytkowników, albo gdy następny pomysł wymaga dużych refaktorów przy małym zysku. Prace nad wydajnością zawsze mają koszt alternatywny; pętla pomaga wydawać czas tam, gdzie się opłaca.

Wybierz metrykę i ustal baseline

Jeśli mierzysz pięć rzeczy naraz, nie będziesz wiedział, co się poprawiło. Wybierz jedną metrykę główną dla tej investigacji i traktuj resztę jako sygnały pomocnicze. Dla wielu problemów z interfejsem ta metryka to latencja. Dla pracy batchowej może to być przepustowość, czas CPU, użycie pamięci albo nawet koszt chmury na uruchomienie.

Bądź konkretny co do scenariusza. „API jest wolne” to za mało. „POST /checkout z typowym koszykiem 3 produktów” da się zmierzyć. Utrzymuj stabilne wejścia, by liczby miały sens.

Zapisz baseline i szczegóły środowiska zanim dotkniesz kodu: rozmiar zestawu danych, typ maszyny, tryb budowania, feature flagi, współbieżność i rozgrzewka. Ten baseline jest twoim punktem odniesienia. Bez niego każda zmiana może wyglądać jak postęp.

Dla latencji polegaj na percentylach, nie tylko na średniej. p50 pokazuje typowe doświadczenie, podczas gdy p95 i p99 ujawniają bolesny ogon, na który skarżą się użytkownicy. Zmiana, która poprawia p50, lecz pogarsza p99, wciąż może być odbierana jako wolniejsza.

Zdecyduj wcześniej, co oznacza „istotne”, żeby nie świętować szumu:

• Latencja: co najmniej 10% poprawy p95 (lub stały próg, np. 50 ms)
• Przepustowość: co najmniej 5% więcej żądań/s przy tym samym error rate
• CPU lub pamięć: redukcja wystarczająca, by uniknąć skalowania lub crashy
• Koszt: mierzalny spadek na uruchomienie lub na 1,000 żądań

Gdy te reguły są ustalone, możesz testować pomysły bez przesuwania celu.

Zbieraj dowody za pomocą profilowania i prostych metryk

Zacznij od najprostszego sygnału, któremu ufasz. Pojedyncze zmierzenie czasu trwania requestu potrafi powiedzieć, czy masz prawdziwy problem i jak duży on jest. Głębsze profilowanie zostaw, gdy musisz wyjaśnić, dlaczego jest wolno.

Dobry dowód zwykle pochodzi z mieszanki źródeł:

• Logi aplikacji (czas trwania requestu, rate błędów, najwolniejsze endpointy)
• APM/traces (gdzie leci czas między serwisami)
• Output profilera lub flame graph (gorące funkcje i stosy wywołań)
• Statystyki bazy danych (wolne zapytania, oczekiwania na locki, cache hit rate)
• Metryki infrastruktury (CPU, pamięć, sieć, restarty kontenerów)

Używaj prostych metryk, gdy pytanie brzmi „czy jest wolniej i o ile?”. Profiluj, gdy pytanie brzmi „gdzie idzie czas?”. Jeśli p95 latency podwoiło się po wdrożeniu, zacznij od timingów i logów, by potwierdzić regresję i określić zasięg. Jeśli timingi pokażą, że większość opóźnienia jest w kodzie aplikacji (a nie w DB), profil CPU lub flame graph mogą wskazać dokładną funkcję, która urosła.

Trzymaj pomiary bezpieczne. Zbieraj to, co potrzebne do debugowania wydajności, nie treści użytkownika. Preferuj agregaty (czasy trwania, liczniki, rozmiary) zamiast surowych payloadów i domyślnie zaciemniaj identyfikatory.

Szum jest realny, więc bierz wiele próbek i notuj outliery. Uruchom ten sam request 10–30 razy i zapisz medianę i p95 zamiast jednego najlepszego przebiegu.

Zapisz dokładny przepis testowy, aby móc go powtórzyć po zmianach: środowisko, zestaw danych, endpoint, rozmiar body, poziom współbieżności i sposób zbierania wyników.

Zamień dowody w jasną hipotezę

Zacznij od nazwania objawu: „p95 latency skacze z 220 ms do 900 ms w szczytach”, „CPU siedzi na 95% na dwóch rdzeniach” albo „pamięć rośnie o 200 MB na godzinę”. Mglista formułka „wydaje się wolne” prowadzi do losowych zmian.

Następnie przetłumacz co zmierzyłeś na obszar podejrzany. Flame graph może pokazać, że większość czasu idzie na kod JSON, trace może wskazać wolną ścieżkę wywołań, a statystyki DB — jedno zapytanie dominujące łączny czas. Wybierz najmniejszy obszar, który wyjaśnia większość kosztu: funkcję, jedno zapytanie SQL albo jedno zewnętrzne wywołanie.

Dobra hipoteza to jedno zdanie, dające się przetestować i powiązane z przewidywaniem. Proszę o pomoc w przetestowaniu pomysłu, a nie o narzędzie, które „cudownie” przyspieszy wszystko.

Prosty szablon hipotezy

Użyj tego formatu:

• Z powodu (dowód), (podejrzane miejsce) powoduje (objaw).
• Jeśli zmienimy (konkretne zachowanie), to (metryka) powinna poprawić się o (przybliżoną wartość).
• Będziemy wiedzieć, że zadziałało, jeśli (wynik ponownego pomiaru).

Przykład: „Ponieważ profil pokazuje 38% CPU w SerializeResponse, przydzielanie nowego bufora na każde żądanie powoduje skoki CPU. Jeśli będziemy ponownie używać bufora, p95 latency powinien spaść o ~10–20% a CPU o ~15% przy tym samym obciążeniu.”

Trzymaj się uczciwości, nazywając alternatywy, zanim dotkniesz kodu. Może wolne jest rzeczywiście upstream, contentacja locków, zmiana hit rate cache'a albo rollout, który zwiększył rozmiar payloadu.

Zapisz 2–3 alternatywne wyjaśnienia i wybierz to, które najlepiej wspiera dowód. Jeśli twoja zmiana nie ruszy metryki, masz już gotową następną hipotezę.

Jak używać Claude Code bez dryfu w stronę zgadywania

Claude jest najbardziej przydatny, gdy traktujesz go jak starannego analityka, nie wyrocznię. Powiąż każde sugestie z tym, co zmierzyłeś, i upewnij się, że każdy krok można obalić.

Daj mu realne wejścia, a nie mglisty opis. Wklej małe, skupione dowody: podsumowanie profilowania, kilka linii logów wokół wolnego requestu, plan zapytania i konkretną ścieżkę kodu. Dołącz liczby „przed” (p95, CPU, DB time), aby znał baseline.

Poproś o wytłumaczenie, co dane sugerują, a czego nie. Potem wymuś konkurencyjne wyjaśnienia. Warto kończyć promptem: „Podaj 2–3 hipotezy i dla każdej powiedz, co ją sfalsyfikowałoby.” To ogranicza zatrzaśnięcie się przy pierwszej rozsądnej historii.

Zanim zmienisz cokolwiek, poproś o najmniejszy eksperyment, który potwierdzi wiodącą hipotezę. Niech będzie szybki i odwracalny: dodaj jeden timer, włącz jedną flagę profilera albo uruchom EXPLAIN dla zapytania.

Jeśli chcesz ściślejszą strukturę wyników, poproś o:

• Co dowody wskazują (i z jakim poziomem pewności)
• 2–3 hipotezy z testem falsyfikującym dla każdej
• Najmniejszą zmianę w kodzie lub konfiguracji, by przetestować top hipotezę
• Dokładnie jaką metrykę zmierzyć ponownie i oczekiwany kierunek

Jeśli nie jest w stanie nazwać konkretnej metryki, lokalizacji i oczekiwanego wyniku, wracasz do zgadywania.

Rób minimalne, odwracalne zmiany

Mając dowód i hipotezę, powstrzymaj się przed „posprzątaniem wszystkiego”. Prace wydajnościowe są najszybciej zaufane wtedy, gdy zmiana jest mała i łatwa do cofnięcia.

Zmieniaj jedną rzecz na raz. Jeśli poprawiasz zapytanie, dodajesz cache i refaktoryzujesz pętlę w jednym commicie, nie dowiesz się, co pomogło (lub zaszkodziło). Zmiany pojedynczej zmiennej sprawiają, że następny pomiar ma sens.

Zanim dotkniesz kodu, zapisz, czego oczekujesz w liczbach. Przykład: „p95 latency powinien spaść z 420 ms poniżej 300 ms, a czas DB powinien zmaleć o ~100 ms.” Jeśli wynik nie osiągnie celu, szybko uczysz się, że hipoteza była słaba lub niepełna.

Trzymaj zmiany odwracalne:

• Preferuj mały diff, który da się łatwo cofnąć.
• Umieść zmianę za prostą flagą, aby można ją było szybko wyłączyć.
• Unikaj refaktorów, które zmieniają nazwy, formatowanie i logikę jednocześnie.
• Ogranicz zakres: jeden endpoint, jedna gorąca ścieżka, jedno kosztowne wywołanie.
• Dodaj krótką notkę w commit message z oczekiwanymi before/after metrykami.

„Minimalne” nie znaczy „błahe”. Znaczy skupione: cache dla jednej kosztownej funkcji, usunięcie jednego powtarzanego przydziału w ciasnej pętli albo pominięcie pracy dla żądań, które tego nie potrzebują.

Dodaj lekkie timery wokół podejrzanego wąskiego gardła, by zobaczyć, co się ruszyło. Pojedynczy timestamp przed i po wywołaniu (logowany lub zebrany jako metryka) potwierdzi, czy twoja zmiana trafiła w problem, czy tylko przesunęła czas gdzie indziej.

Mierz ponownie i decyduj, co dalej

Po zmianie uruchom dokładnie ten sam scenariusz, którego użyłeś w baseline: te same wejścia, środowisko i kształt obciążenia. Jeśli test zależy od cache lub rozgrzewki, sprecyzuj to (np. „pierwszy przebieg zimny, następne 5 ciepłe”). W przeciwnym razie „znajdziesz” poprawy będące przypadkiem.

Porównuj wyniki używając tych samych metryk i percentyli. Średnie mogą ukrywać ból – obserwuj p95 i p99 oraz throughput i czas CPU. Wykonaj wystarczającą liczbę powtórzeń, by zobaczyć stabilizację liczb.

Zanim będziesz świętować, sprawdź regresje, które niekoniecznie widać w jednym nagłówkowym numerze:

• Poprawność: odpowiedzi dalej zgodne z oczekiwaniami.
• Rate błędów: timeouty, 5xx, retry.
• Pamięć: większy szczyt lub ciągły wzrost.
• Ogon latency: p99 pogorszył się mimo lepszego p50.
• Koszt zasobów: CPU lub DB wzrosły.

Następnie decyduj na podstawie dowodu, nie nadziei. Jeśli poprawa jest realna i nie wprowadziła regresji, zostaw ją. Jeśli wyniki są mieszane lub hałaśliwe, cofnij i sformułuj nową hipotezę albo jeszcze bardziej odizoluj zmianę.

Jeśli pracujesz na platformie takiej jak Koder.ai, wykonanie snapshotu przed eksperymentem może uczynić rollback prostym krokiem, co ułatwia bezpieczne testowanie odważnych pomysłów.

Na koniec zapisz, czego się nauczyłeś: baseline, zmiana, nowe liczby i wniosek. Krótka notatka zapobiega powtórzeniu tych samych ślepych zaułków w następnej rundzie.

Typowe błędy, które marnują czas

Prace nad wydajnością zazwyczaj idą w bok, gdy tracisz ciągłość między tym, co zmierzyłeś, a tym, co zmieniłeś. Trzymaj czysty łańcuch dowodów, aby móc z pewnością powiedzieć, co poprawiło lub pogorszyło sytuację.

Najczęstsze przewinienia:

• Naprawianie złego celu: świętujesz szybsze p50, a ogon (p95/p99) nadal jest zły.
• Zmiana wielu rzeczy naraz: refaktory, cache i modyfikacje zapytań w jednym commicie oznaczają, że nie wiesz, co zadziałało.
• Wierzenie jednemu hałaśliwemu przebiegowi: lokalny benchmark, który waha się o 20% między uruchomieniami, to nie dowód.
• Traktowanie pojedynczego profile jako całej prawdy: flame graph wskazuje parsowanie JSON, ale requesty się piętrzą podczas spowolnień DB.
• Porównywanie gruszek z jabłkami: różne zbiory danych, feature flagi, hardware czy poziomy współbieżności, a potem wyciąganie wniosków.

Mały przykład: endpoint wygląda na wolny, więc stroisz serializator, bo jest gorący w profilu. Testujesz ponownie na mniejszym zestawie i wydaje się szybszy. W produkcji p99 się pogarsza, bo DB nadal jest wąskim gardłem, a twoja zmiana powiększyła payload.

Jeśli używasz Claude Code do proponowania poprawek, trzymaj go krótko na smyczy. Poproś o 1–2 minimalne zmiany, które pasują do zebranego dowodu i nalegaj na plan ponownego pomiaru przed akceptacją patcha.

Szybka checklista przed ogłoszeniem „szybsze”

Twierdzenia o szybkości rozpadają się, gdy testy są niejasne. Zanim świętujesz, upewnij się, że możesz wytłumaczyć, co mierzyłeś, jak to mierzyłeś i co zmieniłeś.

Zacznij od nazwania jednej metryki i zapisania baseline'u. Uwzględnij szczegóły, które zmieniają liczby: typ maszyny, obciążenie CPU, rozmiar danych, tryb builda (debug vs release), feature flagi, stan cache i współbieżność. Jeśli nie potrafisz odtworzyć setupu jutro, nie masz baseline'u.

Checklista:

• Metryka i baseline zapisane z notatkami środowiskowymi (hardware, config, dane, zimny/ciepły cache).
• Kroki testowe spisane i powtarzalne.
• Masz jedną hipotezę z przewidywaniem (np. „jeśli usuniemy N+1 zapytań, p95 powinien spaść o ~30%”).
• Wprowadziłeś jedną małą, odwracalną zmianę i udokumentowałeś co się ruszyło (plik, funkcja, zapytanie, ustawienie).
• Ponownie zmierzyłeś z wieloma próbkami i porównałeś porównywalne wyniki (te same wejścia, to samo obciążenie).

Gdy liczby wyglądają lepiej, zrób szybki pass regresyjny. Sprawdź poprawność (te same outputy), rate błędów i timeouty. Obserwuj efekty uboczne jak większa pamięć, skoki CPU, wolniejszy start czy większe obciążenie DB. Zmiana, która poprawia p95, ale podwaja pamięć, może być złą wymianą.

Przykład: krok po kroku badanie wolnego endpointu API

Zespół zgłasza, że GET /orders jest w porządku w dev, ale zwalnia na staging przy umiarkowanym obciążeniu. Użytkownicy skarżą się na timeouty, ale średnia latencja wygląda „w porządku”, co jest klasyczną pułapką.

Najpierw ustal baseline. Przy stabilnym teście obciążeniowym (te same dane, ta sama współbieżność, ten sam czas) zapisujesz:

• p95 latency: 1.8s (cel < 600ms)
• CPU API: ~70% z okazjonalnymi skokami
• DB: jedno zapytanie trwa 900–1100ms, a łączny czas zapytań na request to ~1.3s

Zbierz dowody. Szybki trace pokazuje, że endpoint wykonuje główne zapytanie o zamówienia, potem w pętli pobiera powiązane elementy dla każdego zamówienia. Widzisz też, że JSON jest duży, ale czas DB dominuje.

Przekształć to w listę hipotez do przetestowania:

• Wolne zapytanie wymaga indeksu.
• N+1 zapytań mnoży czas DB.
• Serializacja jest wolna przez duży payload.
• Contentacja locków blokuje odczyty podczas zapisów.

Poproś o minimalną zmianę pasującą do najsilniejszego dowodu: usuń oczywiste N+1, pobierając elementy jednym zapytaniem kluczowanym po order ID (albo dodaj brakujący indeks, jeśli plan zapytania pokazuje pełne skanowanie). Trzymaj to odwracalnym i w jednym, skupionym commicie.

Zmierz ponownie tym samym testem obciążeniowym. Wyniki:

• p95 latency: 1.8s → 720ms
• Łączny czas DB: ~1.3s → ~420ms
• CPU: nieco niższe, ale wciąż niestabilne

Decyzja: wdrażamy poprawkę (wyraźna wygrana), potem startujemy drugą pętlę skupioną na pozostałym rozdźwięku i skokach CPU, bo DB już nie jest głównym ograniczeniem.

Kolejne kroki: uczynić ten workflow rutyną

Najszybsza droga do poprawy w badaniach wydajności to traktowanie każdej rundy jak mały, powtarzalny eksperyment. Gdy proces jest spójny, wyniki stają się łatwiejsze do zaufania, porównywania i udostępniania.

Prosty, jednoplacowy szablon pomaga:

• Metryka + jak jest mierzona (narzędzie, komenda, zestaw danych)
• Baseline (liczby, środowisko i kiedy zarejestrowane)
• Hipoteza (jedno zdanie, testowalna)
• Zmiana (mały diff, co zostało dotknięte)
• Wynik (przed/po oraz decyzja)

Zdecyduj, gdzie przechowywać te notatki, żeby nie zniknęły. Wspólne miejsce jest ważniejsze niż idealne narzędzie: folder w repo obok serwisu, dokument zespołowy lub notatki w tickecie. Klucz to odnajdywalność. Ktoś powinien móc znaleźć „p95 spike po zmianie cache” miesiące później.

Uczyń bezpieczne eksperymenty nawykiem. Używaj snapshotów i prostego rollbacku, by móc przetestować pomysł bez strachu. Jeśli budujesz z Koder.ai, Planning Mode może być wygodnym miejscem na zarys planu pomiaru, zdefiniowanie hipotezy i utrzymanie zakresu przed wygenerowaniem zwartego diffu i ponownym pomiarem.

Ustal rytm. Nie czekaj na incydenty. Dodawaj małe checki wydajności po zmianach, takich jak nowe zapytania, endpointy, większe payloady lub aktualizacje zależności. 10-minutowy baseline teraz może zaoszczędzić dzień zgadywania później.