Optymalizacja wydajnosci z Codex

P95 latency twojego API wlasnie przekroczylo 2 sekundy, a dashboard monitoringu jest caly czerwony. Zespol produktowy mowi “napraw wydajnosc”, ale wolne zapytania dotykaja pieciu serwisow, trzech baz danych i warstwy cachowania. Lokalne profilowanie pokazuje inne waskie gardla niz produkcja, poniewaz wolumen danych to jedna tysieczna rzeczywistego ruchu. Musisz znalezc faktyczne waskie gardlo, zoptymalizowac je i udowodnic, ze poprawka dziala przed wdrozeniem. Codex moze profilowac, optymalizowac i benchmarkowac — a dzieki zadaniom chmurowym i probom best-of-N moze eksplorowac wiele strategii optymalizacji rownolegle.

Co wyniesiesz z tej lekcji

• Prompty do identyfikacji i profilowania waskich gardel wydajnosci w calym stacku
• Workflow zadan chmurowych z uzyciem --attempts do rownoleglej eksploracji optymalizacji
• Techniki benchmarkowania optymalizacji z powtarzalnymi wynikami
• Przepis na automatyzacje cotygodniowego wykrywania regresji wydajnosci

Workflow

Krok 1: Zidentyfikuj waskie gardlo

Zacznij w CLI z diagnostycznym promptem. Podaj Codex objawy i pozwol mu zbadac problem.

Wskazówka

Gotowy prompt do diagnostyki wydajnosci:

The GET /api/dashboard endpoint has p95 latency of 2.1 seconds. Acceptable is under 500ms.

Investigate the performance bottleneck:

1. Read the route handler and trace every function call in the request path
2. Identify database queries and estimate their complexity (check for missing indexes, N+1 patterns, full table scans)
3. Check for synchronous operations that could be parallelized
4. Look for unnecessary data fetching (loading full objects when only IDs are needed)
5. Check the caching layer -- is it being used? Is the cache hit rate likely to be low?

Report the top 3 most likely bottlenecks with estimated impact and file paths.
Do NOT fix anything yet. Diagnosis only.

Krok 2: Profiluj za pomoca zadan chmurowych

Dla dokladnego profilowania uzyj srodowiska chmurowego z danymi testowymi o skali produkcyjnej. Zadania chmurowe moga instalowac narzedzia profilujace, generowac obciazenie i raportowac wyniki.

codex cloud exec --env perf-test "Profile the GET /api/dashboard endpoint:

1. Seed the database with 100K users and 12 months of order data using scripts/seed-reports.ts
2. Start the application server
3. Use autocannon to send 100 requests to GET /api/dashboard with a valid auth token
4. Enable Node.js --prof for CPU profiling during the load test
5. Process the profile: node --prof-process isolate-*.log > profile.txt
6. Analyze the profile output and identify:
   - Functions consuming the most CPU time
   - Database query execution times
   - Any blocking operations in the event loop

Report the findings with specific function names, file paths, and millisecond breakdowns."

Krok 3: Eksploruj optymalizacje z Best-of-N

Najlepsza czesc zadan chmurowych dla pracy wydajnosciowej to flaga --attempts. Codex generuje wiele niezaleznych rozwiazan, a ty wybierasz najlepsze. Kazda proba eksploruje inna strategie optymalizacji.

codex cloud exec --env perf-test --attempts 3 "The GET /api/dashboard endpoint is slow because of:
1. N+1 query pattern in the order summary aggregation
2. Missing database index on orders.user_id + orders.created_at
3. No caching for data that changes at most once per day

Optimize the endpoint to achieve p95 latency under 500ms. You may:
- Rewrite queries to eliminate N+1 patterns
- Add database indexes
- Implement a caching layer with appropriate TTL
- Parallelize independent data fetches with Promise.all

After optimization, benchmark with autocannon (100 concurrent connections, 10 seconds) and report the before/after latency comparison.

Run the full test suite after optimization to verify no regressions."

Przy trzech probach Codex moze wyprobowac trzy rozne strategie: jedna skupiona na optymalizacji zapytan, jedna na cachowaniu i jedna na kombinacji. Porownaj wyniki benchmarkow miedzy probami i wybierz podejscie dajace najlepsza poprawe przy najmniejszej zlozonosci.

Krok 4: Benchmarkuj i zweryfikuj lokalnie

Po wybraniu najlepszej optymalizacji z prob chmurowych zastosuj ja lokalnie i uruchom wlasne benchmarki:

W watku worktree:

Apply the query optimization approach from the cloud task. Specifically:

1. Replace the N+1 query in src/services/dashboard.ts with a single aggregation query
2. Add the composite index on orders(user_id, created_at)
3. Add a 5-minute cache with Redis for the dashboard summary data
4. Parallelize the three independent data fetches with Promise.all

After implementation:
- Run the test suite to verify correctness
- Use the integrated terminal to run: npm run benchmark -- --endpoint /api/dashboard
- Report the latency improvement

Krok 5: Zautomatyzuj wykrywanie regresji wydajnosci

Skonfiguruj cotygodniowa automatyzacje, aby wylapywac regresje wydajnosci zanim trafia na produkcje:

Wskazówka

Gotowy prompt automatyzacji do monitorowania wydajnosci:

Weekly performance regression check:

1. Start the dev server with the test database
2. Run benchmarks against these critical endpoints:
   - GET /api/dashboard (target: p95 < 500ms)
   - POST /api/orders (target: p95 < 200ms)
   - GET /api/users/:id (target: p95 < 100ms)
3. Compare results to the baseline in perf-baseline.json
4. If any endpoint's p95 latency increased by more than 20% from baseline:
   - Identify which recent commits touched the relevant code paths
   - Analyze the changes for performance impact
   - Report the regression with root cause analysis

If performance is stable or improved, update the baseline file.

Gdy cos sie nie uda

Lokalne profilowanie nie odpowiada produkcji. Najwieksza pulapka w pracy wydajnosciowej. Twoja lokalna baza danych ma 1000 wierszy; produkcja ma 50 milionow. Zapytanie skanujace 1000 wierszy w 5ms zajmie 250 sekund skanujac 50 milionow. Zawsze testuj z danymi o skali produkcyjnej w srodowiskach chmurowych. Dolacz “seed the database with at least 100K rows before benchmarking” w swoich promptach.

Cachowanie naprawia objaw, ale wprowadza bledy z nieaktualnymi danymi. Dodanie cache’u poprawia latency, ale tworzy problemy ze spojnoscia. Powiedz Codex: “If you add caching, also implement cache invalidation for the specific scenarios that change the underlying data. Include tests that verify cache invalidation works.”

Proby Best-of-N optymalizuja rozne rzeczy. Przy trzech probach mozesz dostac trzy prawidlowe, ale niekompatybilne optymalizacje. Nie da sie ich wszystkich zmergowac. Wybierz jedno podejscie lub popros Codex o polaczenie najlepszych elementow: “Take the query optimization from attempt 1, the caching strategy from attempt 3, and combine them into a single implementation.”

Wyniki benchmarkow sa niestabilne. Jesli maszyna deweloperska wykonuje inna prace, liczby benchmarkow sa zaszumione. Dolacz iteracje rozgrzewkowe i wiele uruchomien w skrypcie benchmarkowym. Powiedz Codex: “Run the benchmark 5 times and report the median p95, not a single run.”

Co dalej

Operacje bazodanowe Zoptymalizuj warstwe bazy danych, ktora czesto jest zrodlem problemow wydajnosciowych

CI/CD z GitHub Action Codex Dodaj benchmarki wydajnosci do pipeline CI, aby automatycznie wylapywac regresje