Optymalizacja wydajności z Codex

Poziom 3 Poradnik Zaktualizowano 2026-10-12

Optymalizacja wydajności z Codex to pętla w czterech etapach: diagnoza w trybie tylko do odczytu, która wskazuje wąskie gardło, harness benchmarku zapisany w commicie przed jakąkolwiek poprawką, zadania chmurowe best-of-N (codex cloud exec --attempts, maksymalnie cztery próby) sprawdzające konkurencyjne strategie oraz deterministyczna bramka, która przyjmuje zmianę tylko wtedy, gdy przechodzą własny benchmark i testy zespołu.

Ten przewodnik jest dla programistów odpowiedzialnych za wolny serwis i dla tech leadów, którzy decydują, kiedy zmianę wydajnościową można zmergować. P95 twojego API przekroczyło dwie sekundy, dashboard świeci na czerwono, a wolne żądanie przechodzi przez trzy serwisy, bazę danych i cache. Baza na twoim laptopie ma jedną tysięczną wierszy produkcji, więc lokalny profil wskazuje zły kod. Polecenia na tej stronie sprawdzono na Codex CLI 0.157.1 w dniu 2026-09-26.

Co zyskasz dzięki tej pętli

Prompt diagnostyczny w trybie tylko do odczytu, który zwraca uszeregowane wąskie gardła ze ścieżkami plików i dowodami, a niczego nie zmienia.
Harness benchmarku i baseline zapisany w repozytorium, których Codex nie może edytować, więc deklarowane przyspieszenie jest zmierzone.
Zadanie chmurowe best-of-N, które sprawdza do czterech strategii optymalizacji, oraz polecenia do porównania prób i zastosowania jednej z nich.
Sekwencję weryfikacji, która dowodzi poprawności zmiany bez czytania każdej linii diffu.
Cotygodniowe wykrywanie regresji, w którym o wyniku decyduje skrypt, a Codex tylko wyjaśnia porażkę.

Etap wcześniejszy to codzienna eksploatacja Codex. Warunek wstępny: środowisko chmurowe Codex, którego skrypt setup potrafi wypełnić bazę danymi testowymi; zobacz środowiska chmurowe Codex. Tę samą pętlę dla innych agentów opisują analiza wydajności z Claude Code i optymalizacja wydajności z Cursorem.

Dlaczego praca nad wydajnością z Codex zaczyna się od benchmarku, a nie od poprawki?

Agent poproszony o „przyspieszenie” podaje liczbę, która pochodzi z przebiegu, którego nie widziałeś, na danych, których nie wybrałeś. Zmiany wydajnościowe psują się też po cichu: cache serwujący nieaktualne dane albo indeks blokujący tabelę na produkcji przechodzą testy jednostkowe. Dlatego kolejność jest stała:

Diagnozuj w sandboksie tylko do odczytu, żeby nic się nie zmieniło, gdy patrzysz.
Zacommituj benchmark i baseline, zanim powstanie jakakolwiek optymalizacja.
Pozwól Codex sprawdzać strategie na tym benchmarku w izolowanych kontenerach chmurowych.
Uruchom benchmark ponownie sam, poza agentem, i merguj tylko na podstawie tego wyniku.

Każdy krok poniżej daje artefakt, który sprawdzasz w następnym kroku: raport, harness, zestaw diffów oraz wynik „przechodzi” albo „nie przechodzi”.

Zdiagnozuj wąskie gardło bez zmieniania kodu

Zacznij diagnozę w sandboksie tylko do odczytu: Codex czyta kod i uruchamia polecenia tylko do odczytu, ale nie edytuje plików. Diagnoza wymaga głębszego rozumowania, a GPT-6.1 Sol (domyślny model Codex) działa z wysiłkiem low, dopóki go nie podniesiesz. Uruchom w terminalu, w katalogu głównym repozytorium:

codex --sandbox read-only -c model_reasoning_effort="high"

Jeśli masz już skonfigurowany dla Codex serwer MCP bazy danych w trybie tylko do odczytu (widać go w codex mcp list), Codex może uruchomić EXPLAIN na prawdziwych planach zapytań zamiast je zgadywać. Jakich serwerów użyć i jak utrzymać je w trybie tylko do odczytu, opisuje optymalizacja wydajności na produkcji.

GET /api/dashboard has a p95 latency of 2.1 s in production; the target is under 500 ms.
Do not edit any files. Diagnosis only.

1. Start at the route handler and trace every call in the request path, including
   middleware, service calls, database queries, and cache reads.
2. For every database query, record the file and line, the tables it touches, and whether
   it runs once per request or once per row (N+1). If a database MCP server is available,
   run EXPLAIN on each query and quote the plan; otherwise say that the plan is unverified.
3. Flag sequential awaits on independent calls, full objects loaded where only IDs are used,
   and cache reads whose key includes a per-request value such as a timestamp.
4. Rank the top three bottlenecks by expected impact. For each one give the evidence
   (plan, loop, or code path), the file paths, and a way to measure it in isolation.

Separate what you verified from what you inferred.

Ostatnia linia jest ważniejsza, niż wygląda. Diagnoza, która miesza zmierzone plany z domysłami, każe ci optymalizować domysł. Każde wąskie gardło oznaczone jako „inferred” traktuj jako hipotezę do potwierdzenia benchmarkiem.

Zbuduj harness benchmarku, którego Codex nie obejdzie

Harness jest wyrocznią dla wszystkiego, co dalej, więc trafia do osobnego commita przed jakąkolwiek optymalizacją. Dwie zasady czynią go wiarygodnym:

Dane w skali produkcyjnej. Wygeneruj co najmniej 100 000 wierszy w tabelach wskazanych przez diagnozę, z realistycznym rozkładem (kilku ciężkich użytkowników, wielu lekkich). Wzorce N+1 i brakujące indeksy są niewidoczne przy tysiącu wierszy.
Powtarzalne wyniki. Żądania rozgrzewające, kilka przebiegów i mediana p95 z każdego z nich. Pojedynczy przebieg na obciążonej maszynie mierzy maszynę.

Create a benchmark harness for GET /api/dashboard. Do not change application code.

1. scripts/seed-perf.ts: seed 100,000 users and 12 months of orders, with 5% of users
   owning 60% of the orders. Make it idempotent and deterministic (fixed random seed).
2. perf/bench.mjs: start from an already running server at BASE_URL, send 200 warm-up
   requests, then run autocannon with 50 connections for 20 seconds, five times.
   Print JSON: {"endpoint", "runs": [p50, p95, p99 per run], "median_p95"}.
   Exit with code 1 if median_p95 is more than 10% above perf/baseline.json.
   If perf/baseline.json is missing, print the JSON and exit 0 without comparing.
3. Run the seed and the benchmark, then write the result to perf/baseline.json.
4. Add a "perf" section to AGENTS.md: "Files in perf/ and scripts/seed-perf.ts are the
   benchmark oracle. Never edit them in an optimization task."

Report the exact commands you ran and the median p95.

Ten diff przejrzyj sam; to jedyny diff w pętli, który warto przeczytać linia po linii, bo każda późniejsza decyzja na nim polega. Potem zapisz go w osobnym commicie. Od tej chwili każdy diff optymalizacyjny, który dotyka perf/ albo scripts/seed-perf.ts, odrzucasz bez dyskusji.

Uruchom konkurencyjne optymalizacje jako zadania chmurowe best-of-N

codex cloud exec --attempts N uruchamia N niezależnych agentów na tym samym prompcie; każdy daje własny diff. CLI przyjmuje wartości od 1 do 4 i odrzuca każdą inną (sprawdzone na 0.157.1), a całe codex cloud jest oznaczone jako eksperymentalne. Każda próba to osobny przebieg agenta, który zużywa 5-godzinny i tygodniowy limit twojego planu, więc N prób zużywa mniej więcej N razy tyle limitu co jedna; zobacz zarządzanie kosztami Codex.

Best-of-N opłaca się w pracy nad wydajnością, bo strategie mają różne kompromisy: przepisane zapytanie zmienia jeden plik, cache dodaje infrastrukturę i problem unieważniania, a równoległe pobieranie zmienia obsługę błędów. Próby z tym samym promptem mają tendencję do zbiegania się, więc nazwij alternatywy i wymagaj, żeby każda próba podała swój wybór.

Zanim wyślesz zadanie, środowisko chmurowe musi umieć uruchomić harness: jego skrypt setup instaluje zależności, uruchamia bazę i wykonuje scripts/seed-perf.ts. Skrypty setup, cache i dostęp agenta do internetu opisuje strona środowiska chmurowe Codex. Najpierw wypchnij commit z harnessem, bo kontener klonuje twoją gałąź ze zdalnego repozytorium.

Reduce the median p95 of GET /api/dashboard below 500 ms, measured by perf/bench.mjs.

The diagnosis found: (1) an N+1 query in src/services/dashboard.ts when summarizing
orders, (2) no index on orders(user_id, created_at), (3) three independent fetches
awaited one after another.

Pick exactly ONE primary strategy and state it in the first line of your summary:
A) rewrite the queries into one aggregation plus the composite index;
B) parallelize the independent fetches and remove the N+1 with a batched loader;
C) cache the summary per user with a TTL of 5 minutes, with invalidation on order writes.

Rules:
- Do not edit anything in perf/, scripts/seed-perf.ts, or existing test assertions.
- Put any index in a new migration file. On PostgreSQL, use CREATE INDEX CONCURRENTLY.
- If you add a cache, add a test that writes an order and proves the next read is fresh.
- Run scripts/seed-perf.ts, then perf/bench.mjs on the unchanged code and again after
  your change, in this same container. Quote both JSON outputs.
- Run the full test suite and quote the command and its result.

Wyślij je z terminala, w repozytorium, z promptem zapisanym w pliku:

git push origin perf/dashboard
codex cloud exec --env perf-test --branch perf/dashboard --attempts 3 - < prompts/dashboard-perf.md

perf-test to etykieta albo ID twojego środowiska chmurowego, a - czyta prompt ze standardowego wejścia. Polecenie wypisuje URL zadania; jego ID to TASK_ID w poleceniach poniżej.

Wybierz próbę na podstawie dowodów, a nie najlepszej liczby

Zanim otworzysz jakikolwiek diff, porównaj próby na podstawie metadanych i liczb:

# Status, liczba prób i rozmiar każdego zadania w tym środowisku
codex cloud list --env perf-test --json \
  | jq '.tasks[] | {id, status, attempt_total, summary}'

# Zapisz diff każdej próby do porównania
for n in 1 2 3; do codex cloud diff TASK_ID --attempt "$n" > "attempt-$n.diff"; done

Kontener to nie twój sprzęt produkcyjny, więc porównuj wynik „przed” i „po” każdej próby w tym samym kontenerze, a nie bezwzględne milisekundy między próbami. Potem zestaw zysk z tym, co próba dokłada:

Pytanie	Wybierz próbę, która…	Odrzuć, gdy…
Czy osiągnęła cel?	Schodzi poniżej 500 ms, z wynikiem „przed” i „po” z tego samego kontenera	Nie podaje wyniku „przed” albo ma tylko jeden przebieg
Jak duża jest zmiana?	Dotyka najmniejszej liczby plików przy danym zysku	Dotyka `perf/`, asercji testów albo snapshotów
Co dokłada do utrzymania?	Nie dodaje nowego serwisu	Dodaje cache bez testu świeżości danych
Czy migracja jest bezpieczna?	Buduje indeks bez blokowania	Buduje indeks, który blokuje gorącą tabelę

Do not edit any files. Read attempt-1.diff, attempt-2.diff and attempt-3.diff and the
task summaries I paste below.

For each attempt report: the strategy it claims (A, B or C), the before and after
median_p95 it quoted, the files it changed, and whether it touched perf/,
scripts/seed-perf.ts, test assertions, snapshots, or lockfiles.
Flag any cache without an invalidation test and any index built without CONCURRENTLY.
Recommend one attempt with the reason, or say none is acceptable and what the
follow-up prompt must add. Do not combine attempts unless I ask.

Jeśli dwie próby wygrywają każda na innym wąskim gardle, zastosuj jedną, zaktualizuj baseline i uruchom drugie zadanie dla kolejnego wąskiego gardła. Ręcznie sklejone dwie próby to nowa, niezmierzona zmiana.

Zweryfikuj optymalizację bez czytania każdej linii

Liczby podane przez agenta mówią ci, którą próbę sprawdzić, a nie czy ją zmergować. Weryfikacja odbywa się poza agentem, a zatwierdza ją konkretna osoba.

Zastosuj próbę w czystym worktree. Uruchom w terminalu, z głównego checkoutu:

git fetch origin perf/dashboard
git worktree add --detach ../verify-perf origin/perf/dashboard && cd ../verify-perf
codex cloud apply TASK_ID --attempt 2
git diff --stat -- perf/ scripts/seed-perf.ts   # nie może nic wypisać

Uruchom bramki samodzielnie. Uruchom sprawdzanie typów, linter i pełny zestaw testów, a potem seed i benchmark: node perf/bench.mjs kończy się kodem niezerowym, gdy mediana p95 przekracza baseline o więcej niż 10%. Liczy się ta liczba, a nie ta z podsumowania zadania.
Sprawdź plan zapytania, nie kod. Jeśli zmiana dodaje indeks, uruchom EXPLAIN na nowym zapytaniu w bazie wypełnionej danymi testowymi (po scripts/seed-perf.ts) i potwierdź, że plan go używa. Indeks złożony z kolumnami w złej kolejności kompiluje się, przechodzi testy i nic nie daje.
Otwórz pull request z dowodami. Wklej do opisu JSON „przed” i „po” oraz plan zapytania i poproś o @codex review na pull requeście. Każdą migrację i zmianę cache skieruj do właściciela kodu serwisu; zobacz code review z Codex.
Udowodnij zysk na produkcji i zachowaj drogę odwrotu. Wdrażaj za flagą funkcji albo na canary, porównaj p95 tego samego endpointu w danych tracingu aplikacji w tym samym oknie czasowym i wycofaj zmianę, jeśli nie ma poprawy. Osoba, która wysłała zadanie, odpowiada za merge i za decyzję o wycofaniu.

Gdy zmiana przejdzie, zaktualizuj perf/baseline.json w osobnym commicie, żeby kolejne sprawdzenie regresji mierzyło względem nowej liczby.

Wykrywaj regresje wydajności co tydzień

Cotygodniowe sprawdzenie utrzymuje zysk. O wyniku niech decyduje skrypt, a Codex niech tylko wyjaśnia porażkę, bo agent zapytany „czy wydajność spadła?” potrafi przekonać sam siebie do każdej odpowiedzi.

Zaplanuj node perf/bench.mjs w CI (na przykład cotygodniowy wyzwalacz schedule). Gdy skrypt kończy się kodem niezerowym, uruchom nieinteraktywny krok Codex (codex exec) w trybie tylko do odczytu, który zapisuje diagnozę do pliku:

status=0
node perf/bench.mjs > perf/latest.json || status=$?   # działa też pod bash -e na runnerach CI
if [ "$status" -ne 0 ]; then
  codex exec --sandbox read-only --ephemeral -o perf/triage.md - < prompts/perf-triage.md
fi
exit "$status"

Pobierz pełną historię repozytorium (na przykład fetch-depth: 0 w actions/checkout), bo inaczej git log w kroku diagnozy widzi tylko jeden commit. Skrypt zachowuje kod wyjścia benchmarku, więc przy regresji zadanie CI pozostaje czerwone, a powiadomienia o nieudanym zaplanowanym przebiegu nadal działają; plik z diagnozą jest załącznikiem do tej porażki, a nie werdyktem. -o (--output-last-message) zapisuje ostatnią wiadomość do pliku, który zadanie CI może dołączyć do issue, a --ephemeral nie zapisuje sesji na dysku. Ustaw zadaniu CI timeout, bo codex exec nie ma limitu wydatków (sprawdzone na 0.157.1). Uwierzytelnianie, sekrety i plik workflow opisują strony CI/CD z Codex oraz uruchamianie Codex bez interakcji. Żeby uruchamiać to samo sprawdzenie z aplikacji desktopowej, zobacz automatyzacje Codex.

Do not edit any files. perf/latest.json shows a median p95 above the limit in
perf/baseline.json.

1. Quote both numbers and the endpoint.
2. List the commits since the date of perf/baseline.json that touched files in the
   request path of that endpoint (git log with paths), newest first.
3. For the three most likely commits, explain the mechanism: new query, removed index,
   added await, larger payload, or cache key change. Cite file and line.
4. Propose one experiment per suspect that would confirm or clear it, such as
   benchmarking with that commit reverted.

Mark every claim as verified (you ran or read it) or inferred.

Diagnozę czyta człowiek i decyduje o następnym kroku: revert, nowe zadanie optymalizacyjne albo świadomie przyjęty kompromis i nowy baseline.

Co się psuje w pracy nad wydajnością z Codex?

Objaw	Przyczyna	Naprawa
Poprawka jest szybka lokalnie i wolna na produkcji	Dane benchmarku dużo mniejsze niż produkcyjne	Zasil bazę danymi w skali produkcyjnej w skrypcie setup środowiska chmurowego; zaktualizuj baseline przed kolejną próbą
Benchmark się poprawia, a użytkownicy nie widzą zmiany	Próba edytowała harness, seed albo test	Odrzucaj każdy diff dotykający `perf/`; trzymaj regułę „benchmark oracle” w `AGENTS.md` i sprawdzaj `git diff --stat` w kroku 1 weryfikacji
Wszystkie próby dają to samo podejście	Ten sam prompt bez nazwanych alternatyw	Nazwij strategie i wymagaj, żeby każda próba podała swój wybór
Wyniki skaczą między przebiegami	Obciążona maszyna, brak rozgrzewki, jeden przebieg	Pięć przebiegów, żądania rozgrzewające, mediana p95; porównuj „przed” i „po” w jednym kontenerze
Użytkownicy widzą nieaktualne dane po zmianie cache	TTL bez unieważniania przy zapisie	Wymagaj w prompcie testu świeżości; wyłącz flagę, potem dodaj unieważnianie
Wdrożenie blokuje tabelę	Indeks budowany blokującym poleceniem na gorącej tabeli	Buduj bez blokowania (`CREATE INDEX CONCURRENTLY` w PostgreSQL) w osobnej migracji; zobacz praca z bazą danych w Codex
Diagnoza nie wskazuje żadnych podejrzanych commitów	Płytki checkout w CI, więc `git log` widzi jeden commit	Pobierz pełną historię (`fetch-depth: 0`) w zaplanowanym zadaniu
Best-of-N wyczerpuje tygodniowy limit	Cztery próby dla mechanicznej zmiany	Używaj prób tylko tam, gdzie strategie się różnią; jedna próba dla znanej poprawki

Dokąd dalej z wydajnością

Środowiska chmurowe Codex: skrypty setup, dostęp do sieci i best-of-N w szczegółach.
Testy obciążeniowe, stresowe i benchmarki: zamień harness w test obciążeniowy i bramkę CI dla każdego serwisu.
Optymalizacja wydajności na produkcji: diagnoza regresji p99, wyczerpania puli połączeń i autoskalowania z serwerami MCP tylko do odczytu.
Praca z bazą danych w Codex: zapytania, indeksy i migracje, które agent pisze bezpiecznie.
Zarządzanie kosztami Codex: ile best-of-N i zaplanowane przebiegi kosztują względem twojego limitu.
Audyt bezpieczeństwa z Codex: następna strona na tym etapie.