awesome-everything EN
↑ Обратно к восхождению

Производительность

Измерительный цикл: микробенч, макробенч, prod-профиль, эффект наблюдателя

Суть Три области измерения лгут при неправильном применении. Эффект наблюдателя: профайлер возмущает систему — знай насколько.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на middle-высоте — в небе
◷ 18 min

Инженер переписывает горячую функцию на ассемблере. Микробенчмарк показывает 8x ускорение. Задеплоенный сервис стал быстрее на 3%. Production-профиль предсказал бы этот результат за 60 секунд — до переписывания.

Три области измерения

Микробенчмарк — одна функция в изоляции, без нагрузки, без I/O, повторяется миллионы раз. Инструменты: testing.B в Go, JMH для Java, Criterion для Rust, Benchmark.js. Лучший для: сравнения двух реализаций одного примитива (какая хэш-функция быстрее?). Лжёт когда: используется для предсказания задержки на уровне приложения — функция может занимать 4% production-времени вне зависимости от её изолированной скорости.

Макробенчмарк — полная система под синтетической нагрузкой, имитирующей продакшен. Инструменты: k6, JMeter, locust, vegeta. Лучший для: валидации end-to-end поведения перед выкаткой. Лжёт когда: синтетическая нагрузка не отражает реальный трафик (микс запросов, размеры тел, состояние кэша).

Production-профиль — непрерывное профилирование с накладными расходами 2-5%, захватывающее реальный трафик, реальное состояние кэша, реальный параллелизм. Лучший для: честного поиска следующего узкого места. Ограничение: можно запускать только в продакшене, поэтому он не ответит «поможет ли это изменение» до выкатки.

Рабочий процесс сеньора использует все три: микробенч для сравнения альтернатив, макробенч для end-to-end валидации, prod-профиль для поиска следующей цели.

ОбластьПравильный вопросНеверный вопросКлючая ловушка
МикробенчРеализация A быстрее реализации B?Ускорит ли это наш API?JIT warmup, dead-code elimination, кэш слишком тёплый
МакробенчСистема выдерживает SLO под нагрузкой?Что реально происходит в продакшене?Синтетическая нагрузка может не совпадать с реальной формой трафика
Prod-профильКаково следующее узкое место?Поможет ли кандидатный фикс?Нельзя предсказать до выкатки; показывает только текущее состояние

Эффект наблюдателя

Каждое измерение возмущает систему.

Сэмплирующий профайлер на 100 Гц добавляет 0.5-2% накладных расходов от обхода стеков. На 1000 Гц — до 10%. Инструментирующие профайлеры (таймит каждый вход/выход из функции) добавляют 20-100% в JIT-рантаймах, потому что оптимизатор больше не может инлайнить теперь обёрнутые функции. Debug-сборка с хуками профайлера ведёт себя совсем не как release-сборка.

Следствие: выбирай измерение, которое минимально возмущает систему для данного вопроса. Используй сэмплирующие профайлеры для продакшена. Используй инструментирующие профайлеры для плотных микробенчмарков, где важны точные счётчики вызовов.

Всегда измеряй дважды: один раз без профайлера, один — с ним, и проверь, что основная метрика (throughput, latency p99) отличается не более чем на 5%. Если отличается больше — профайлер наблюдает другую систему, чем та, что работает в продакшене.

Полный измерительный цикл детально

«Сначала профиль» — не разовое действие, а повторяющийся цикл.

  1. Воспроизведи медленный сценарий под реалистичной нагрузкой — replay production-трафика, нагрузочный тест на staging или живая канарейка.
  2. Сними baseline-профиль достаточной длительности для статистической значимости (30 секунд при 100 Гц дают 3000 сэмплов — типичный минимум).
  3. Прочитай профиль — назови hotspot конкретными цифрами: «функция X потребляет 38% CPU; вызывается по пути Y; средний self-time 220 мс на запрос».
  4. Сформулируй одну гипотезу о фиксе и предскажи ожидаемое ускорение по закону Амдала.
  5. Примени фикс изолированно — только то изменение, которое предсказал.
  6. Сними новый профиль под той же нагрузкой и сравни с baseline; убедись, что hotspot уменьшился на предсказанную величину.
  7. Выкати и наблюдай продакшен. Пропуск любого шага возвращает цикл в режим угадывания.
Почему это работает

«Профилировать продакшен слишком дорого» — это отговорка, которая обходится дороже, чем само профилирование. Сэмплирующий профайлер на 100 Гц добавляет менее 2% нагрузки на CPU. Узкое место, которое он найдёт за первые пять минут production-трафика, стоит на порядки больше, чем те 2%, которые ушли на его поиск.

Проследи
1/5

Команде сообщили, что checkout API медленный. Прокрути profile-first ответ от начала до конца.

1
Step 1 of 5
Шаг 1: «медленный» — не измерение. Что делаешь первым?
2
Locked
Шаг 2: цифры есть — что дальше?
3
Locked
Шаг 3: профиль показывает 70% CPU в JSON-сериализации внутри кастомного audit-логгера. Интуиция команды — база. Что теперь?
4
Locked
Шаг 4: изменение применено, новый профиль снят. Что проверяешь?
5
Locked
Шаг 5: rollout в продакшен. За чем наблюдаешь?
Викторина

Команда профилирует только на staging (синтетическая нагрузка), никогда в продакшене. После деплоя perf-улучшения p99 в продакшене стал хуже. Наиболее вероятное системное объяснение?

Викторина

Инструментирующий профайлер (таймит каждый вход/выход функции) показывает, что функция занимает 40 мс. Сэмплирующий профайлер показывает 8 мс. Какой с большей вероятностью отражает production-поведение?

Расставь шаги по порядку

Расставь шаги расследования жалобы «сервис медленный» по порядку — от первого до последнего:

  1. 1 Квантифицируй жалобу: выбери метрику (p99 задержки, throughput, error rate) и целевое значение
  2. 2 Воспроизведи под реалистичной нагрузкой при видимой метрике (живая канарейка, staging replay)
  3. 3 Сними baseline-профиль достаточной длительности для статистической значимости
  4. 4 Прочитай профиль: назови топовую функцию по self-time и доле CPU
  5. 5 Вычисли потолок Амдала для фикса этой функции — реши, оправдана ли победа
  6. 6 Сформулируй одну гипотезу фикса, предскажи суммарное ускорение, примени только это изменение
  7. 7 Сними новый профиль под той же нагрузкой и сравни с baseline
  8. 8 Выкати на канарейку, потом в продакшен, наблюдая за метрикой на устойчивое улучшение
Вспомните перед уходом
  1. 01
    Инженер переписывает горячую функцию на ассемблере. Микробенч показывает 8x. Задеплоенный сервис: 3% быстрее. Проведи диагностику.
  2. 02
    Почему нужно всегда проверять, что накладные расходы профайлера укладываются в 5% от базовой основной метрики, прежде чем доверять профилю?
Итог

Три области измерения существуют потому, что каждая честно отвечает на разный вопрос и по-разному лжёт. Микробенч изолирует две реализации, но не может предсказать production-долю. Макробенч валидирует end-to-end, но зависит от того, насколько синтетическая нагрузка совпадает с реальным трафиком. Production-профиль — единственное по-настоящему честное измерение того, что медленно прямо сейчас, но не может предсказать влияние не выкаченного изменения. Рабочий процесс сеньора сцепляет все три. Эффект наблюдателя: каждый профайлер возмущает систему: сэмплирующие добавляют менее 2%, инструментирующие — 20-100% в JIT-рантаймах. Всегда проверяй, что основная метрика остаётся в пределах 5% при работающем профайлере.

Связанные уроки
встречается в159
Продолжить восхождение ↑Чтение флейм-графов: формы, профайлеры по языкам и 60-секундный скан
хоткеи развернуть
поиск
K
пред. пьеса
k
след. пьеса
j
тиры
t
это меню
?
sources3
expand
  1. 01
  2. 02
  3. 03

Trademarks belong to their respective owners. Editorial reference only.