Классификация и исправление: сопоставление family bottleneck с методами

Два инженера смотрят на один и тот же flame graph. Один видит “GC горячий” и переписывает аллокатор. Другой видит “GC горячий из-за объёмного upstream-payload” и откатывает один деплой. Первый тратит неделю; второй — 35 минут. Разница — в классификации: назвать family bottleneck до прикосновения к коду.

Восемь family bottleneck

Семь фрагментов этой главы отображаются на небольшой словарь family bottleneck. Если правильно классифицировать hotspot, набор исправлений следует немедленно.

Амдал до написания кода

Закон Амдала: если доля f времени выполнения приходится на hotspot, максимальное ускорение от его устранения — 1 / (1 - f).

Если hotspot — 40% CPU (f = 0,4), максимально возможное ускорение — 1 / 0,6 = 1,67x. Если SLO требует 3x улучшения, это не тот hotspot. Вернитесь к шагу 2 и снова профилируйте.

Этот расчёт занимает 30 секунд. Он предотвращает недели работы над неправильной целью.

Пример: Сервис checkout имеет p99 = 800 мс и цель менее 200 мс. Профиль показывает:

• json.Marshal: 28% CPU
• runtime.scanobject: 22% CPU
• pgx.Query: 18% CPU (через trace spans — фактически I/O)

Амдал только по Marshal: 1 / (1 - 0,28) = 1,39x. Это снижает 800 мс до ~575 мс — всё ещё выше цели. Амдал по Marshal + scanobject вместе (50%): 1 / 0,5 = 2x. Это даёт ~400 мс — всё ещё выше цели. Добавляя I/O-путь (68% всего): 1 / 0,32 = 3,1x. Это даёт ~258 мс — близко.

Настоящая первопричина: все три горячих фрейма разделяют один upstream, который вдруг начал возвращать в 10 раз больше данных. Устранить upstream — и все три фрейма уменьшатся вместе. Общий выигрыш: 6x. Расчёт по Амдалу наглядно показал, что исправление любой одной family по отдельности было недостаточным.

Кросс-слойное компаундирование

Реальные bottleneck редко сидят в одном слое. Медленная checkout-страница может состоять из 30% parse JS-бандла на клиенте, 20% N+1-запросов в бэкенде, 15% GC allocation pressure и 35% compute бэкенда. Исправление любого одного слоя изолированно даёт только Amdahl-ограниченный выигрыш на итоговой метрике.

Составной эффект — настоящий выигрыш. Два инженера, работающих параллельно — один над бандлом, другой над запросами и GC — каждый добивается 2x улучшения, дают совокупный 4x по headline-метрике. Без кросс-слойного мышления разговор стопорится: “мы уже оптимизировали свою часть.”

Словарь классификации family из главы позволяет инженерам по frontend, backend и infra описывать свой bottleneck так, чтобы другие слои понимали. Без общего словаря весь разговор сводится к “бэкенд медленный” — “нет, фронтенд медленный”.