Тестирование производительности
Тестирование производительности как практика — пропускная способность, задержка и время отклика, снятие базовой линии, моделирование реалистичной нагрузки в JMeter или k6, длительные прогоны на выносливость, вертикальная и горизонтальная масштабируемость и поиск настоящего узкого места.
7 вопросов
JuniorТеорияОчень частоЧто такое базовая линия производительности и зачем снимать её до любой оптимизации?
Что такое базовая линия производительности и зачем снимать её до любой оптимизации?
Базовая линия — набор чисел производительности: перцентили времени отклика, пропускная способность, доля ошибок, снятые на известной сборке, в известном окружении, под известным профилем нагрузки. Без неё нельзя сказать, помогло изменение или навредило: каждый следующий прогон сравнивают с ней, и это превращает подозрение на регресс в измеримый факт.
Типичные ошибки
- ✗Оптимизировать до измерения, не имея с чем сравнить результат
- ✗Снимать базовую линию, не зафиксировав сборку, окружение и профиль нагрузки
- ✗Брать за базу самый быстрый отклик вместо перцентилей
Уточняющие вопросы
- →Что делает базовую линию недействительной и заставляет снять новую?
- →Почему окружение надо зафиксировать, чтобы базовая линия что-то значила?
JuniorТеорияОчень частоЧем различаются пропускная способность, задержка и время отклика, и зачем перцентили?
Чем различаются пропускная способность, задержка и время отклика, и зачем перцентили?
Пропускная способность — объём работы в единицу времени, запросы в секунду. Время отклика — сколько длится один запрос, а задержка — промедление до начала работы. Это независимые оси: пропускная способность может расти, пока время отклика рушится. Отчитывайтесь перцентилями — p95, p99 — а не средним, которое прячет медленный хвост, ощущаемый пользователями.
Типичные ошибки
- ✗Отчитываться средним временем отклика вместо перцентилей p95 и p99
- ✗Считать пропускную способность и время отклика одной метрикой
- ✗Полагать, что высокая пропускная способность автоматически означает быстрый отклик
Уточняющие вопросы
- →О чём говорит p99, который в 40 раз больше медианы?
- →Почему пропускная способность может стоять на месте, пока время отклика растёт?
MiddleТеорияЧастоПод нагрузкой система тормозит — как найти настоящее узкое место, а не гадать?
Под нагрузкой система тормозит — как найти настоящее узкое место, а не гадать?
Узкое место — единственный ресурс, что насыщается первым и ограничивает пропускную способность. Наращивайте нагрузку ступенями от базовой линии, следя за всеми ресурсами — CPU, память, I/O, база, пул потоков, блокировки — и за тем, где копится очередь. Это тот, что упирается в предел, пока у прочих есть запас; исправьте его — и оно сместится, измеряйте заново.
Типичные ошибки
- ✗Гадать по коду вместо наблюдения за ресурсами под реальной нагрузкой
- ✗Гнаться за самым медленным запросом, а не за насыщенным ресурсом
- ✗Считать узким местом всегда базу и пропускать поиск
Уточняющие вопросы
- →Почему устранение одного узкого места часто просто смещает его на следующий ресурс?
- →Как отличить насыщенный ресурс от просто занятого?
MiddleТеорияЧастоЧем тестирование вертикальной масштабируемости отличается от горизонтальной?
Чем тестирование вертикальной масштабируемости отличается от горизонтальной?
Вертикальная — это узел помощнее: больше CPU и RAM; горизонтальная — больше узлов за балансировщиком. Тестируют обе, добавляя ресурс ступенями и строя график пропускной способности, отслеживая, где кривая перестаёт быть линейной. Вертикаль упирается в потолок железа; горизонталь вскрывает общее узкое место — базу, блокировку, липкие сессии, — ограничивающее выигрыш.
Типичные ошибки
- ✗Менять определения местами — называть scale-out вертикалью, а scale-up горизонталью
- ✗Мерить задержку одного запроса вместо пропускной способности от добавленного ресурса
- ✗Считать масштабирование всегда линейным и игнорировать общее узкое место
Уточняющие вопросы
- →Какой общий ресурс на практике чаще всего ограничивает горизонтальное масштабирование?
- →Как заметить точку, где добавленные узлы перестают помогать пропускной способности?
MiddleДизайнИногдаВаша команда собирается нагрузочно тестировать API оформления заказа интернет-магазина. Есть три месяца продовых логов доступа и дашборд APM, поэтому реальный состав трафика известен: примерно 70% чтений каталога, 20% поиска, 8% изменений корзины, 2% заказов, с пиками около 1200 запросов в секунду вечером в будни и куда более резким всплеском во время ежемесячной распродажи. Нагрузочное окружение — уменьшенная копия прода: втрое меньше узлов приложения, но та же база данных. Базовая линия уже снята, использовать можно JMeter или k6. Опишите, как вы смоделируете нагрузку, чтобы прогон говорил о проде правду: что возьмёте из логов, как распределите приход виртуальных пользователей во времени и с чем будете сравнивать результат.
Ваша команда собирается нагрузочно тестировать API оформления заказа интернет-магазина. Есть три месяца продовых логов доступа и дашборд APM, поэтому реальный состав трафика известен: примерно 70% чтений каталога, 20% поиска, 8% изменений корзины, 2% заказов, с пиками около 1200 запросов в секунду вечером в будни и куда более резким всплеском во время ежемесячной распродажи. Нагрузочное окружение — уменьшенная копия прода: втрое меньше узлов приложения, но та же база данных. Базовая линия уже снята, использовать можно JMeter или k6. Опишите, как вы смоделируете нагрузку, чтобы прогон говорил о проде правду: что возьмёте из логов, как распределите приход виртуальных пользователей во времени и с чем будете сравнивать результат.
Профиль строится по логам, а не по догадке: воспроизведите состав эндпоинтов и их веса, сохраните think time и состояние сессии, чтобы виртуальный пользователь вёл себя как человек, и наращивайте приход ступенями до цели, а не стартуйте сразу на полную. Целевую нагрузку масштабируйте под уменьшенное окружение, а результат сравнивайте с базовой линией по тем же перцентилям.
Типичные ошибки
- ✗Придумывать состав эндпоинтов вместо того, чтобы вывести его из продовых логов
- ✗Стартовать сразу на полной нагрузке, без разгона и без think time между запросами
- ✗Читать числа с уменьшенного окружения так, будто это числа прода
Уточняющие вопросы
- →Как смоделировать всплеск распродажи иначе, чем вечерний пик?
- →Каким числам с окружения втрое меньше прода можно верить, а каким нельзя?
MiddleТеорияИногдаЧто такое длительный тест на выносливость и какие сбои он ловит, а короткий прогон пропускает?
Что такое длительный тест на выносливость и какие сбои он ловит, а короткий прогон пропускает?
Тест на выносливость держит умеренную, приближенную к проду нагрузку часами или сутками. Он нацелен на медленный сбой, до которого короткий прогон не доживает: утечки памяти, пул, не возвращающий хэндлы, диски, забиваемые логами, ползущее вверх время отклика. Судят по трендам ресурсов во времени, а не по одному пиковому числу.
Типичные ошибки
- ✗Путать тест на выносливость со стресс-тестом — высокая интенсивность вместо долгой длительности
- ✗Гонять его слишком кратко, чтобы утечка или медленный дрейф успели накопиться
- ✗Оценивать по пиковому числу вместо трендов ресурсов во времени
Уточняющие вопросы
- →За какими графиками ресурсов вы бы следили в ночном прогоне и почему?
- →Как отличить настоящую утечку памяти от обычного прогрева кэша по тренду?
SeniorДизайнРедкоВаш процесс оформления заказа вызывает внешнего платёжного провайдера на каждый заказ. Это чёрный ящик: инструментировать его нельзя, тестового тенанта нет, а договор запрещает гнать синтетическую нагрузку на его прод — жёсткие удары грозят банами по rate-limit, реальными комиссиями за транзакции и деградацией сервиса для других клиентов провайдера. При этом приёмка производительности релиза зависит от понимания, как оформление ведёт себя под пиковой нагрузкой, а вызов платежа лежит на критическом пути. У вас есть три месяца собственных логов с реальным распределением задержек и доли ошибок провайдера и его опубликованный SLA. Спроектируйте подход, позволяющий нагрузочно протестировать оформление и подписать приёмку, не нагружая саму третью сторону: скажите, на что подавать нагрузку, как представить провайдера и что именно измерять и отчитывать.
Ваш процесс оформления заказа вызывает внешнего платёжного провайдера на каждый заказ. Это чёрный ящик: инструментировать его нельзя, тестового тенанта нет, а договор запрещает гнать синтетическую нагрузку на его прод — жёсткие удары грозят банами по rate-limit, реальными комиссиями за транзакции и деградацией сервиса для других клиентов провайдера. При этом приёмка производительности релиза зависит от понимания, как оформление ведёт себя под пиковой нагрузкой, а вызов платежа лежит на критическом пути. У вас есть три месяца собственных логов с реальным распределением задержек и доли ошибок провайдера и его опубликованный SLA. Спроектируйте подход, позволяющий нагрузочно протестировать оформление и подписать приёмку, не нагружая саму третью сторону: скажите, на что подавать нагрузку, как представить провайдера и что именно измерять и отчитывать.
Не нагружайте провайдера — замените его заглушкой, воспроизводящей распределение задержек и доли ошибок из ваших логов и его SLA, включая медленный хвост. Нагрузку подавайте только на своё оформление, проверяя его поведение вокруг него: таймаут ограничивает вызов, повторы идут с backoff, а circuit breaker и запасной путь держат его отзывчивым, когда провайдер медлит. Отчитывайтесь сквозными перцентилями и деградацией; реальное число снимайте лишь в согласованном rate-limit или песочнице.
Типичные ошибки
- ✗Гнать синтетический пик на реальный продовый эндпоинт провайдера
- ✗Убирать зависимость из теста и считать её бесконечно быстрой
- ✗Заглушать лишь счастливый путь, а не медленный хвост и ответы с ошибкой
Уточняющие вопросы
- →Как вывести распределение задержек и ошибок заглушки из ваших логов и SLA?
- →Что заставило бы вас настоять на небольшом реальном измерении вопреки ограничениям?
