Performance Engineering: Profiling, Flame Graphs, Tail Latency

Зачем

Performance — это продукт, а не «то, что мы дотюним к релизу». Цифры жёсткие: +100ms latency у Amazon = −1% sales; +500ms у Google = −20% трафика. Медленная-но-корректная система всегда проигрывает быстрой-и-корректной в B2C и почти всегда в B2B. Performance engineering — это методология, а не «попрофилил и нашёл узкое место»: измерь baseline → найди самый большой bottleneck → почини → провалидируй → повтори. Без методологии оптимизация превращается в полировку микросекунд там, где они не нужны, пока 1-секундная функция рядом остаётся нетронутой.

Mental model

«Сначала измеряй, потом оптимизируй.» Donald Knuth: premature optimization is the root of all evil — но полная цитата заканчивается «yet we should not pass up our opportunities in that critical 3%». Performance engineering — это работа по нахождению того самого 3% и игнорированию остальных 97%.

Три инструмента дают разный ответ на разный вопрос:

• Metrics (RED — Rate/Errors/Duration) — «что медленнее, чем должно быть?»
• Traces (Jaeger/Tempo span waterfall) — «где конкретно в цепочке вызовов?»
• Profiles (flame graph) — «почему именно эта функция съедает CPU/память?»
• Logs — «с какими аргументами это случилось?»

В сумме они образуют drill-down: алерт по RED → trace показывает виновный span → profile показывает виновную функцию → лог даёт контекст запроса. Brendan Gregg в Systems Performance (2nd ed., 2020) формализует это как USE-method для ресурсов (Utilization/Saturation/Errors) и workload characterization для нагрузки.

Что на диаграмме

Минимальный production-стенд:

• Production service — lb → api (3 реплики, 5K RPS) → cache (Redis) + db (PostgreSQL). Типичная веб-архитектура, на которой видны все классические bottleneck-сценарии.
• Profiling stack — pprof endpoint, Pyroscope (continuous profiler, scrape каждые 10s, ~1% CPU overhead), Flame graph UI. Пара pprof+Pyroscope — современный де-факто стандарт для continuous profiling в проде.
• SRE tooling — k6 (synthetic load), Prometheus (RED-метрики), Grafana (p99-дашборд), Tempo (distributed traces).
• Engineer — on-call инженер, который запускает нагрузочный тест, читает flame graph, проверяет SLO в Grafana.
• Users — реальный трафик; именно их p99 в итоге важнее любого синтетического бенчмарка.

Рёбра — это физические соединения, а не направление данных. Например, edge api → pprof существует один раз: ответ на scrape от Pyroscope летит обратно по тому же ребру (reverse animation), отдельного ребра pprof → pyroscope нет.

Сценарии

CPU flame graph → fix. Классический drill-down: алерт «p99 800ms (SLO 200ms)» → Grafana показывает линейный рост за 2 недели → engineer открывает Pyroscope → flame graph: 60% CPU в jackson.ObjectMapper.writeValueAsString → root cause: на каждый запрос пересоздаётся ObjectMapper → fix: вынести в static final синглтон → валидация: p99 = 220ms. 4× ускорение от 10 строк кода. Это ровно то, ради чего нужен профайлер: интуиция сказала бы «надо больше нод», профайлер показал реальную причину.

Continuous profiling diff. Pyroscope scrape-ит /debug/pprof каждые 10s, теги по service.version. После деплоя v2.4 авто-алерт: «новая функция compress.gzipBody = +25% CPU». Diff между v2.3 и v2.4 показывает один новый стек. Root cause: PR #4821 включил gzip на каждый ответ, включая JSON < 1KB (где CPU-cost компрессии больше, чем сэкономленный байт). Fix: gzip только > 8KB. Без continuous profiling эта регрессия жила бы недели, пока кто-то случайно не запустил локальный профайлер.

Load test → tail at p99. k6 ramp 100→5000 RPS. На первый взгляд всё ок: mean = 45ms, CPU 60%. Но Grafana p99 = 2.8s, p99.9 = 8.1s — это и есть Tail at Scale (Dean & Barroso, CACM 2013). Trace показывает: 95% хвоста — в db-span. Root cause: PostgreSQL autovacuum блокирует hot table на 2 секунды. Mean соврал — 1% пользователей видит 2.8s. Два fix: (A) тюнить autovacuum_vacuum_cost_limit, чтобы размазать работу; (B) hedged requests (Dean) — переотправлять запрос, если ответа нет к p95. Итог: p99 = 280ms, mean не сдвинулся.

Trade-offs (ADR)

ADR-001: Profile-then-fix vs scale-out

Контекст. Когда p99 растёт, есть два пути: (a) добавить реплик / взять instance побольше — быстро (1 день), но линейно умножает infra-cost навсегда; (b) спрофилировать и оптимизировать hot-функцию — медленно (1–2 недели), но компаундится: выигрыш получает каждый будущий запрос.

Решение. Сначала всегда профилируем, если у одной ноды есть < 10× headroom. Оптимизируем top-3 функции на flame graph, если хоть одна > 15% CPU. Горизонтальный scale включаем только когда (1) flame flat (никакая функция > 5%), либо (2) задача честно embarrassingly parallel и stateless. Для stateful (DB, брокеры) horizontal scale — last resort: шарды добавляют ops-сложность на годы вперёд.

ADR-002: Continuous profiling > ad-hoc local profiling

Контекст. Локальное профилирование на синтетическом workload систематически прячет настоящий bottleneck — data scale, concurrency, cache state, mix запросов не совпадают с продом. Инженер неделю гоняется не за тем хот-спотом, потом видит prod-профиль и охреневает. Continuous profiling (Pyroscope/Parca через eBPF) стоит ~1% CPU и захватывает каждый коммит на реальном трафике.

Решение. Pyroscope (или Parca) на каждой prod-ноде с day 1. Профили тегируются по версии сервиса, чтобы можно было сделать diff v2.4 vs v2.3. Авто-алерт на регрессии > 10% в любой top-5 функции. Локальный профайл разрешён только для прототипирования fix-а, никогда как источник правды о том, «что медленно».

ADR-003: Mean latency запрещена в SLO

Контекст. Команда годами репортила mean latency, потому что «он стабильный и красивый на графиках». Tail при этом был катастрофой — 1% юзеров видел 2-секундные страницы.

Решение. SLO формулируется только в терминах p99 и p99.9. Mean можно показывать для отладки, но не как KPI. Hedged requests / tied requests рассматриваются по умолчанию для любых fan-out > 10 (Dean & Barroso: при fan-out на 100 серверов с p99=1s, 63% запросов увидят 1s где-нибудь).

Реальные системы

• Google «The Tail at Scale» (Dean & Barroso, CACM 2013) — основополагающая статья про tail latency. Источник идей hedged/tied requests.
• Discord — Go → Rust для Read States (2020) — GC-паузы в Go давали p99-спайки до 100ms. После миграции — стабильный sub-millisecond. Public blog post, классический case study про GC pressure как bottleneck.
• Stripe — YJIT в Ruby 3.1 (2022) — +15% throughput без изменения кода. Один флаг. Иллюстрирует, что иногда самый дешёвый win — runtime upgrade.
• Cloudflare — Go GC tuning (Marek Majkowski, 2018) — снижение allocations в Workers runtime упростило GC, улучшило p99.
• Netflix — async-profiler в проде — кейсы через блог Brendan Gregg (сейчас в Intel). Sample-based, low overhead, понимает JVM-стеки.
• AWS S3 — целевой p99 ~100ms PUT/GET за decade — постоянная работа над per-request overhead. Performance budget как первоклассное ограничение.
• Pyroscope / Parca / Polar Signals (2020–2024) — поколение continuous-profiling tools, превратившее профилирование из «локальной экзотики» в always-on prod-инструмент через eBPF.

Anti-patterns

• Premature optimization — оптимизация без profile. Читаемость хуже, gain нулевой. Knuth's original sin.
• Late performance work — performance как finishing touch. К концу проекта архитектура такая, что fix невозможен без rewrite.
• Локальный профайл на синтетике — см. ADR-002. Prod ≠ local: данные, concurrency, mix запросов.
• Mean latency в SLO — прячет хвосты. Используй p99/p99.9. См. ADR-003.
• Optimize before architecture — добавил cache на N+1 query вместо того, чтобы убрать N+1.
• Забыл EXPLAIN — missing index это 10–1000× win на одной команде. Самая дешёвая оптимизация в мире.
• No regression detection — perf деградирует постепенно. Нужны бенчмарки в CI или continuous-profile diff (ADR-002).
• Optimize the wrong thing (Pareto violation) — профайл говорит «80% в DB», ты оптимизируешь сериализацию (5%).
• Single-machine benchmark на distributed system — local fast, prod slow (network, partition, fan-out tail).
• Ignore JIT warmup — первые 1000 запросов медленные, потом быстрые. Бенчмарк без warmup врёт.
• Mean latency в дашборде, который смотрит executive — он начнёт принимать решения по mean. Скрой mean, оставь только p99.

Когда НЕ использовать

Performance engineering как дисциплина имеет цену: профайлеры, observability, нагрузочные тесты, время инженеров. Бывают ситуации, когда это не первый приоритет:

• Очень ранний прототип / pre-PMF. Если ты не уверен, что продукт нужен — оптимизация преждевременна в продуктовом смысле, а не только в кнуттовском. Сначала найди PMF, потом дотюнишь.
• Внутренний tool на 10 пользователей. Time-to-fix важнее p99. 2-секундный latency приемлем, если экономит неделю разработки.
• Compute-cheap workload. Если ты тратишь $50/мес на инфраструктуру, неделя профилирования стоит дороже, чем масштабирование до $200/мес. Считай ROI инженерного времени против infra.
• Workload, где «правильно» важнее «быстро». Финансовая отчётность, медицинские расчёты, криптография. Сначала добейся корректности, потом оптимизируй (и только после ревью, что оптимизация не сломала semantics).
• Когда нет SLO. Performance без целевых чисел — это эстетика, а не инженерия. Сначала договорись с бизнесом о p99 / cost / throughput targets, потом оптимизируй под них.

И отдельно: не оптимизируй то, что юзер не чувствует. Если функция выполняется раз в сутки в background — её 5s vs 50ms никому не интересен. Hot path первичен.

Дальше читать

• [CONCEPT]latency-vs-throughput — фундаментальный trade-off; почему batching повышает throughput, но и latency.
• [CONCEPT]observability-pillars — metrics/logs/traces/profiles как четыре столпа; performance engineering без них слепое.
• [CONCEPT]red-use-methods — формализация USE (для ресурсов) и RED (для сервисов) от Brendan Gregg и Tom Wilkie.
• [CONCEPT]distributed-tracing — span waterfall, отвечающий на вопрос «где медленно» в микросервисах.
• [CASE]twitter-system-design — tail latency на fan-out, hedged requests in action.
• [CASE]uber-system-design — гео-индексы, p99 на матчинге водитель↔райдер.
• Brendan Gregg, «Systems Performance» (2nd ed., 2020) — главная книга. Free chapters: http://www.brendangregg.com/sysperfbook.html
• Brendan Gregg, «BPF Performance Tools» (2019) — eBPF deep dive, основа современного continuous profiling.
• Dean & Barroso, «The Tail at Scale» (CACM 2013) — https://research.google/pubs/pub40801/
• Neil Gunther, «Guerrilla Capacity Planning» — USL (Universal Scalability Law), knee-point analysis.
• Pyroscope docs — https://grafana.com/docs/pyroscope/
• Discord Rust migration — https://discord.com/blog/why-discord-is-switching-from-go-to-rust
• Web.dev performance budgets — https://web.dev/performance-budgets-101/