Optymalizacja wydajności z Codex

P95 latency twojego API właśnie przekroczyło 2 sekundy, a dashboard monitoringu jest cały czerwony. Zespół produktowy mówi “napraw wydajność”, ale wolne zapytania dotykają pięciu serwisów, trzech baz danych i warstwy cachowania. Lokalne profilowanie pokazuje inne wąskie gardła niż produkcja, ponieważ wolumen danych to jedna tysięczna rzeczywistego ruchu. Musisz znaleźć faktyczne wąskie gardło, zoptymalizować je i udowodnić, że poprawka działa przed wdrożeniem. Codex może profilować, optymalizować i benchmarkować — a dzięki zadaniom chmurowym i próbom best-of-N może eksplorować wiele strategii optymalizacji równolegle.

Co wyniesiesz z tej lekcji

• Prompty do identyfikacji i profilowania wąskich gardeł wydajności w całym stacku
• Workflow zadań chmurowych z użyciem --attempts do równoległej eksploracji optymalizacji
• Techniki benchmarkowania optymalizacji z powtarzalnymi wynikami
• Przepis na automatyzację cotygodniowego wykrywania regresji wydajności

Workflow

Krok 1: Zidentyfikuj wąskie gardło

Zacznij w CLI z diagnostycznym promptem. Podaj Codex objawy i pozwól mu zbadać problem.

Wskazówka

Gotowy prompt do diagnostyki wydajności:

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 pomocą zadań chmurowych

Dla dokładnego profilowania użyj środowiska chmurowego z danymi testowymi o skali produkcyjnej. Zadania chmurowe mogą instalować narzędzia profilujące, generować obciążenie i raportować 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 część zadań chmurowych dla pracy wydajnościowej to flaga --attempts. Codex generuje wiele niezależnych rozwiązań, a ty wybierasz najlepsze. Każda próba eksploruje inną strategię 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 próbach Codex może wypróbować trzy różne strategie: jedną skupioną na optymalizacji zapytań, jedną na cachowaniu i jedną na kombinacji. Porównaj wyniki benchmarków między próbami i wybierz podejście dające najlepszą poprawę przy najmniejszej złożoności.

Krok 4: Benchmarkuj i zweryfikuj lokalnie

Po wybraniu najlepszej optymalizacji z prób chmurowych zastosuj ją lokalnie i uruchom własne benchmarki:

W wątku 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 wydajności

Skonfiguruj cotygodniową automatyzację, aby wyłapywać regresje wydajności zanim trafią na produkcję:

Wskazówka

Gotowy prompt automatyzacji do monitorowania wydajności:

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 coś się nie uda

Lokalne profilowanie nie odpowiada produkcji. Największa pułapka w pracy wydajnościowej. Twoja lokalna baza danych ma 1000 wierszy; produkcja ma 50 milionów. Zapytanie skanujące 1000 wierszy w 5ms zajmie 250 sekund skanując 50 milionów. Zawsze testuj z danymi o skali produkcyjnej w środowiskach chmurowych. Dołącz “seed the database with at least 100K rows before benchmarking” w swoich promptach.

Cachowanie naprawia objaw, ale wprowadza błędy z nieaktualnymi danymi. Dodanie cache’u poprawia latency, ale tworzy problemy ze spójnością. 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.”

Próby Best-of-N optymalizują różne rzeczy. Przy trzech próbach możesz dostać trzy prawidłowe, ale niekompatybilne optymalizacje. Nie da się ich wszystkich zmergować. Wybierz jedno podejście lub poproś Codex o połączenie najlepszych elementów: “Take the query optimization from attempt 1, the caching strategy from attempt 3, and combine them into a single implementation.”

Wyniki benchmarków są niestabilne. Jeśli maszyna deweloperska wykonuje inną pracę, liczby benchmarków są zaszumione. Dołącz iteracje rozgrzewkowe i wiele uruchomień w skrypcie benchmarkowym. Powiedz Codex: “Run the benchmark 5 times and report the median p95, not a single run.”

Co dalej

Operacje bazodanowe Zoptymalizuj warstwę bazy danych, która często jest źródłem problemów wydajnościowych

CI/CD z GitHub Action Codex Dodaj benchmarki wydajności do pipeline CI, aby automatycznie wyłapywać regresje