Производительность
Сначала профиль: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — потолки Amdahl, self vs cum-time, scope измерений, observer effect, статистические baseline и чтение форм flame graph.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальном расследовании «сервис тормозит» — не определение для заучивания, а суждение, которое надо защитить числами.
Цель
Убедись, что связываешь измерительный цикл, потолок Amdahl, выбор scope, observer effect, статистическую отчётность и чтение flame graph — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
Профиль показывает топ-функцию на 12% общего CPU. Коллега предлагает героический рерайт, который сделает её в 8x быстрее. Прежде чем одобрить — какое число решающее и что оно говорит?
Heads-up Локальный speedup бессмыслен без доли. Amdahl ограничивает общее улучшение через p; 8x на 12%-функции даёт ~12% суммарно, а не 8x.
Heads-up Amdahl позволяет предсказать потолок до единой строки кода. Отгрузить рискованный рерайт, чтобы обнаружить потолок 1.12x, который можно было посчитать — ровно та трата, которую предотвращает profile-first.
Heads-up Self-time говорит ГДЕ работа, а не стоит ли выигрыш. Функция может быть на 100% self-time и при этом всего 12% от общего — Amdahl всё равно ограничивает выигрыш ~12%.
Викторина
Completed
Flame graph показывает одну функцию с cum-time 80%, но self-time 2%, над единственным широким листом. Что это и где живёт фикс?
Heads-up Cum-time включает вызываемых. С self-time 2% собственные инструкции функции почти ничего не стоят; рерайт сэкономит максимум 2%. Реальная стоимость — в том, что она вызывает.
Heads-up Огромный cum-time с крошечным self-time — нормальная, ожидаемая сигнатура HTTP-хендлеров, middleware и dispatch-слоёв. Это инструкция к чтению, а не ошибка.
Heads-up X-позиция в flame graph — алфавитная группировка, а не порядок во времени. Слева-справа ничего не говорит о последовательности выполнения; ширина — это число сэмплов.
Викторина
Completed
Микробенчмарк говорит, что новый хеш в 10x быстрее. Ты хочешь узнать, станет ли быстрее твой API. Какое измерение честно отвечает на это и почему?
Heads-up Итерации чинят дисперсию, а не scope. Микробенч измеряет функцию в изоляции и никогда не скажет её долю в wall-clock API — для этого нужен production-профиль.
Heads-up Если хеширование — 3% времени API, Amdahl ограничивает выигрыш ~1.03x — невидимо пользователям. Рассуждение по категории («хеширование — типичный боттлнек») вместо измерения доли — первородный грех, который предотвращает profile-first.
Heads-up Макробенч валидирует end-to-end, но зависит от того, совпадает ли синтетическая нагрузка с реальным трафиком; это финальная проверка, а не измерение доли. Честный источник p — production-профиль.
Викторина
Completed
Instrumentation-профайлер сообщает горячий Java-метод как 40 мс/вызов; sampling-профайлер — 8 мс/вызов для того же метода. Какой отражает production и что вызывает разрыв?
Heads-up Точный счёт вызовов помогает, только когда стоимость измерения пренебрежима. В JIT-рантайме instrumentation отключает инлайнинг и добавляет 20–100% overhead, поэтому измеряет другую (более медленную) программу, чем работает в production.
Heads-up Тот же метод, те же единицы (мс/вызов), дико разные числа из-за разного уровня возмущения. Observer effect заставляет их измерять разные системы; репрезентативен для production sampling.
Heads-up Hardware counters объясняют ПОЧЕМУ функция горячая (memory- vs compute-bound); они не разрешают разрыв из-за instrumentation-overhead. Это делает sampling.
Викторина
Completed
PR заявляет «на 15% быстрее» по одному staging-прогону. Второй инженер перезапускает тот же неизменённый код и видит разброс 7%. Как читать исходное заявление?
Heads-up Контролируемая не значит без шума. В staging всё равно есть паузы GC, решения планировщика и вариация состояния кэша, дающие разброс 5–10% между идентичными прогонами, как только что показал перезапуск.
Heads-up Два прогона не задают распределение, а mean — неверная статистика: он доминируется выбросами и прячет хвост. Нужны median, p95/p99 и CI минимум по 5 прогонам.
Heads-up Разброс доказывает, что измерение шумное, а не что изменение плохое. Ни один прогон не надёжен в одиночку; нельзя судить о знаке или величине без распределения.
Викторина
Completed
Flame graph показывает тонкие пики, разбросанные по всей ширине, без доминирующего листа, но p99 ужасный. Что говорит форма и что снимать дальше?
Heads-up Тонкие разбросанные пики — узнаваемая, валидная форма, означающая, что время не на CPU. Это диагноз, а не поломка.
Heads-up Плоский CPU значит, что боттлнек off-CPU, а не отсутствует. С плохим p99 время куда-то уходит — в ожидание, к которому CPU-профиль слеп.
Heads-up Бо́льшая частота отрисует ту же разбросанную форму плотнее; она не консолидирует off-CPU время в CPU-хотспот, потому что это время никогда не было на CPU.
Итог
Сквозная линия юнита — одно расследование: квантифицируй жалобу, воспроизведи под реалистичной нагрузкой, сними baseline, читай ФОРМУ прежде имён и дай числам — не интуиции — назвать горячую точку. Потолок Amdahl решает, стоит ли фикс (доля важнее локального speedup); self vs cum-time решает, куда смотреть; выбор scope и observer effect решают, какому измерению верить; статистические baseline решают, реален ли «выигрыш»; а разбросанный flame graph говорит, что боттлнек off-CPU. Каждый неверный ответ выше — реальный способ, которым инженеры обманывают себя, оптимизируя не тот код.