Analiza wydajności z terminala

Twoje API średnio odpowiadało w 120ms trzy miesiące temu. Dzisiaj to 1.8 sekundy. Nikt nie zmienił niczego oczywistego — żaden pojedynczy commit nie wskazuje winowajcy. Zespół produktowy pyta, dlaczego dashboard jest ospały. Zespół infrastruktury już podwoił liczbę serwerów i nie przyniosło to żadnej różnicy. Musisz znaleźć wąskie gardło, ale narzędzia profilowania mają krzywą uczenia się, a ty potrzebujesz odpowiedzi dzisiaj po południu.

Czego się nauczysz

• Workflow Claude Code do profilowania wydajności Node.js, Python i baz danych z terminala bez instalowania dedykowanych narzędzi APM
• Prompty do skopiowania identyfikujące zapytania N+1, nieindeksowane skany tabel, wycieki pamięci i przewymiarowane bundle w twoim kodzie
• Systematyczne podejście do optymalizacji wydajności: mierz, identyfikuj, napraw, zweryfikuj

Znajdowanie wąskiego gardła

Zanim zaczniesz cokolwiek optymalizować, potrzebujesz danych. Claude Code może zinstrumentować twoją aplikację do zbierania danych czasowych bez konieczności korzystania z dostawcy APM.

Wskazówka

Prompt do skopiowania — dodanie instrumentacji wydajnościowej:

Add lightweight performance instrumentation to our API. For every route handler, measure and log: total response time, database query time (aggregate), external API call time, and time spent in business logic (total minus db and external). Log these as structured JSON with the route path and method. Do not use any APM library -- just wrap the existing handlers with timing code using performance.now(). Make it togglable via a PERF_TRACE=1 environment variable so we can turn it off in production.

Po wygenerowaniu instrumentacji przez Claude, uruchom ją na kilku reprezentatywnych zapytaniach:

PERF_TRACE=1 node dist/index.js &
curl http://localhost:3000/api/users
curl http://localhost:3000/api/orders?limit=100
curl http://localhost:3000/api/dashboard

Następnie przekaż wyniki z powrotem do Claude Code:

Here are the performance logs from three API endpoints. Identify which endpoint is slowest, which phase (database, external API, business logic) is the bottleneck, and suggest specific optimizations. Show me the exact queries or function calls that need attention.

Ta pętla zwrotna — instrumentuj, mierz, analizuj, napraw — to podstawowy workflow. Claude Code zajmuje się uciążliwą instrumentacją, podczas gdy ty koncentrujesz się na zrozumieniu wyników.

Optymalizacja zapytań bazodanowych

Najczęstszym problemem wydajnościowym jest baza danych. Wolne zapytania, brakujące indeksy i wzorce N+1 odpowiadają za większość opóźnień backendu.

Wskazówka

Prompt do skopiowania — znajdowanie i naprawianie wolnych zapytań:

Analyze all database queries in our codebase. For each query: 1) identify if it is an N+1 pattern (query inside a loop or called once per item in a list), 2) check if the WHERE clause columns have indexes by looking at our migration files or schema, 3) flag any SELECT * that could be narrowed to specific columns, 4) find queries that fetch more rows than needed (missing LIMIT or pagination). For each problem, show the file location and provide the optimized version.

Claude Code czyta definicje modeli ORM, pliki migracji i handlery tras, aby zbudować kompletny obraz. Na przykład może znaleźć:

// Before: N+1 -- one query per order to fetch the user
const orders = await db.query('SELECT * FROM orders WHERE status = $1', ['pending']);
for (const order of orders) {
  const user = await db.query('SELECT * FROM users WHERE id = $1', [order.userId]);
  order.user = user;
}

// After: Single query with JOIN
const orders = await db.query(`
  SELECT o.id, o.total, o.status, u.name, u.email
  FROM orders o
  JOIN users u ON o.user_id = u.id
  WHERE o.status = $1
`, ['pending']);

Po naprawieniu zapytań poproś Claude Code o wygenerowanie brakujących indeksów:

Based on the queries in our codebase, generate a migration file that adds indexes for all columns used in WHERE clauses, JOIN conditions, and ORDER BY clauses that do not already have indexes. Use CREATE INDEX CONCURRENTLY to avoid locking the table.

Profilowanie czasu odpowiedzi API

Dla endpointów, które są wolne, ale zapytania bazodanowe wyglądają dobrze, problem często tkwi w logice biznesowej — transformacji danych, serializacji lub niepotrzebnych obliczeniach.

Profile our /api/dashboard endpoint. It currently takes 3 seconds. Trace the execution path from the route handler through every function it calls. For each function, estimate the time complexity based on the data structures used. Identify any: 1) nested loops over large arrays, 2) synchronous operations that should be async, 3) repeated computation that could be cached, 4) unnecessary data fetching (fields computed but never sent to the client).

Claude Code prześledzi łańcuch wywołań i oznaczy wzorce takie jak:

• map wewnątrz filter wewnątrz innego map, które mogłoby być jednym przejściem
• Funkcja pobierająca preferencje użytkownika przy każdym zapytaniu, podczas gdy zmieniają się raz dziennie
• Serializacja JSON ogromnego obiektu, gdy klient używa tylko trzech pól

Analiza bundla frontendowego

Wydajność backendu to tylko połowa historii. Jeśli twój bundle JavaScript waży 2 MB, przeglądarka ciężko pracuje, zanim użytkownik zobaczy cokolwiek.

Wskazówka

Prompt do skopiowania — optymalizacja rozmiaru bundla:

Analyze our frontend build output. Check: 1) total bundle size and per-chunk sizes, 2) large dependencies that could be tree-shaken or replaced (moment.js -> date-fns, lodash -> individual imports), 3) code that should be lazy-loaded (route-level code splitting), 4) assets that should be compressed (images, fonts), 5) any duplicate dependencies in the bundle. Generate the specific code changes to reduce total bundle size by at least 30%.

Jeśli twój projekt używa webpack lub Vite, Claude Code może również wygenerować konfigurację analizy:

Add webpack-bundle-analyzer (or rollup-plugin-visualizer for Vite) to our build and generate a treemap HTML report. Also add a CI check that fails if the main bundle exceeds 200 KB gzipped.

Wykrywanie wycieków pamięci

Wycieki pamięci są notorycznie trudne do znalezienia, ponieważ objawiają się powoli. Claude Code może przejrzeć twój kod pod kątem typowych wzorców wycieków bez konieczności robienia heap dumpa.

Review our Node.js application for memory leak patterns. Check for: 1) event listeners added in request handlers but never removed, 2) closures that capture large objects and prevent garbage collection, 3) caches (Maps, arrays) that grow unbounded without eviction, 4) streams that are not properly closed on error, 5) module-level state that accumulates per-request data. For each finding, show the leak pattern and the fix.

Do aktywnego badania wycieków Claude Code może wygenerować skrypt diagnostyczny:

Create a diagnostic endpoint at /debug/memory (only accessible from localhost) that returns: process.memoryUsage(), the count of active event listeners on the global event bus, the sizes of all in-memory caches, and active timer/interval counts. Also create a script that hits this endpoint every 30 seconds and writes the data to a CSV file so we can graph memory growth over time.

Testy obciążeniowe i benchmarki

Po optymalizacji musisz zweryfikować poprawę pod realistycznym obciążeniem. Claude Code może wygenerować skrypty testów obciążeniowych.

Generate a k6 load test script for our API that simulates realistic traffic: 70% reads (GET /api/products with pagination), 20% writes (POST /api/orders with a realistic order payload), 10% search (GET /api/search?q=random_term). Ramp up from 10 to 200 virtual users over 5 minutes, hold for 10 minutes, then ramp down. Assert that p95 response time stays under 500ms and error rate stays under 0.1%.

Uruchom test przed i po optymalizacji, aby skwantyfikować poprawę. Przekaż wyniki z powrotem do Claude Code do analizy:

Here are the k6 results from before and after our optimization. Summarize the improvement in a table showing p50, p95, p99 latency, requests per second, and error rate. Identify any endpoints that did not improve and suggest next steps.

Gdy coś idzie nie tak

Sama instrumentacja spowalnia aplikację. Opakowywanie każdej funkcji kodem mierzącym czas dodaje narzut. Użyj przełącznika PERF_TRACE, aby trzymać go wyłączonego na produkcji. Dla zawsze włączonego monitorowania użyj samplowania: “Update the instrumentation to only measure 1% of requests in production, selected randomly.”

Claude sugeruje indeks, ale migracja blokuje tabele. Na dużych tabelach CREATE INDEX może zablokować zapisy na minuty. Zawsze używaj CREATE INDEX CONCURRENTLY w PostgreSQL. Poproś Claude Code: “This table has 50 million rows and serves write traffic. Generate the index creation as a concurrent, non-locking migration.”

Naprawa N+1 wprowadza masywny JOIN. Czasami joinowanie pięciu tabel jest gorsze niż pięć małych zapytań, szczególnie przy dużych zbiorach wyników. Po wygenerowaniu optymalizacji przez Claude, uruchom EXPLAIN ANALYZE na nowym zapytaniu i wklej wynik: “Here is the EXPLAIN ANALYZE output for the optimized query. Is this plan efficient or should we use a different strategy like a subquery or materialized view?”

Dzielenie bundla spowalnia początkowe ładowanie przez wodospad zapytań. Agresywne dzielenie kodu może tworzyć zbyt wiele małych chunków ładowanych sekwencyjnie. Powiedz Claude o swoim ograniczeniu: “We want at most 5 chunks on the critical path. Merge the route-level chunks for the three most visited pages into the main bundle and only lazy-load the rest.”

Co dalej

Monitoring i obserwowalność Skonfiguruj bieżący monitoring wydajności, aby regresje były wychwytywane zanim użytkownicy je zauważą

Migracje baz danych i kodu Restrukturyzacja schematu pod kątem wydajności w miarę wzrostu danych

Automatyzacja wdrożeń Bezpieczne wdrażanie poprawek wydajności z automatycznym wycofaniem