Как проверяли время ответа

Что проверяют

Понимаете ли вы, что время ответа это распределение, а не одно число, и откуда брались требования к нему. Следом спросят, почему вы смотрели на перцентили, а не на среднее, и как отличали проблему сервиса от проблемы стенда.

Как отвечать

Каркас строится на вашем опыте:

• требование: откуда цифра. Хорошо, если это нефункциональное требование вида «95% запросов поиска быстрее 800 мс при 200 RPS». Если его не было, расскажите, как сформулировали его вместе с аналитиком по данным прода;
• что мерили: время ответа API до последнего байта, время до первого байта, для UI отдельно метрики вроде LCP и INP;
• инструменты: под нагрузкой JMeter, k6, Gatling или Locust, разовые замеры в Postman и DevTools, для фронтенда Lighthouse;
• профиль нагрузки: сценарии по реальной статистике, разогрев, ступенчатый рост, долгий тест на стабильность, а не пять минут;
• метрики: p50, p95, p99, доля ошибок, пропускная способность, параллельно CPU, память и пулы соединений сервера в Grafana;
• итог: где просело, какую причину нашли с разработкой (N+1 запросы, нет индекса, маленький пул), что стало после исправления.

Цифры и инструменты называйте свои. Если нагрузочного тестирования на проекте не было, честно скажите, что время ответа проверяли функционально, ассертом на длительность в автотесте или в DevTools, и объясните, как построили бы полноценный тест.

Где спотыкаются

Говорят о среднем времени. Среднее прячет хвост: при среднем 200 мс каждый двадцатый пользователь может ждать три секунды.

Грузят с одной машины стенд, который слабее прода в разы, и выдают цифры за итог. Нужно назвать ограничения стенда и проверить, не упёрся ли в ресурсы сам генератор нагрузки.

Не отделяют ошибки от медленных ответов. Быстрый 500 улучшает среднее, и отчёт выглядит лучше реальности.