Проводили ли вы тестирование производительности
Что проверяют
Отличаете ли вы нагрузочное тестирование от «погоняли скрипт и посмотрели» и понимаете ли, что его результат это найденное узкое место, а не отметка «прошло».
Как отвечать
Если опыт есть, разложите его по шагам.
- Вид теста. Нагрузочный под ожидаемый профиль, стрессовый до отказа, тест стабильности на несколько часов для поиска утечек, всплесковый, проверка масштабируемости.
- Откуда профиль. Из аналитики прода: распределение запросов по методам, пики по времени суток, объём данных в базе. Придуманное число пользователей не проверяет ничего.
- Инструмент. JMeter, k6, Gatling, Locust. Сценарий бьёт в API, а не ходит через браузер.
- Что меряете. Квантили времени ответа, пропускную способность, долю ошибок, утилизацию процессора и памяти, занятость пула соединений к базе.
- Что нашли. Запрос без индекса, нехватка соединений в пуле, блокировка, паузы сборщика мусора, лишняя сериализация.
Отдельно скажите про стенд: конфигурация и объём данных должны быть сопоставимы с продом, иначе абсолютные числа бессмысленны и годятся только для сравнения с прошлым прогоном. Опыта нет, так и скажите, но добавьте, что умеете: замерить время ответа, найти лишние запросы к базе, прочитать метрики сервиса.
Где спотыкаются
Докладывают среднее время ответа. Среднее скрывает хвост: тяжёлые запросы растворяются в массе быстрых, а жалуются как раз те, кто в этот хвост попал. Рядом нужны квантили и доля ошибок.
Упираются в генератор нагрузки. Одна машина, нехватка процессора или свободных портов, и вы меряете свой скрипт, а не сервис. Проверка простая: добавьте генераторов и посмотрите, вырос ли результат.
Гоняют один прогон без прогрева и без базовой линии. Первый заход попадает в холодные кэши, а без сохранённого прошлого результата отличить регрессию от обычного разброса невозможно.