Нагрузку спрашивают даже у функциональных тестировщиков: что такое перцентиль, какие бывают тесты, каким инструментом пользовались. На senior ждут умения спланировать тест и прочитать результат.
Виды тестов
- Нагрузочный (load): ожидаемая нагрузка, проверка критериев.
- Стрессовый (stress): выше ожидаемой до отказа. Где предел и как система падает и восстанавливается.
- Всплеск (spike): резкий скачок, например начало распродажи или пуш на всех пользователей.
- Стабильности (soak, endurance): обычная нагрузка часами. Ловит утечки памяти, рост соединений, заполнение диска.
- Ёмкости (capacity): сколько выдерживаем на текущем железе и как масштабируемся.
Метрики
Со стороны клиента:
- RPS (запросов в секунду, пропускная способность).
- Время ответа по перцентилям: p50 (медиана), p95, p99.
- Доля ошибок.
Со стороны системы: CPU, память, диск, сеть, пулы соединений, очереди, сборка мусора, медленные запросы в базе. Отчёт генератора без мониторинга системы показывает, что плохо, но не почему.
Перцентили
p95 = 300 мс значит: 95% запросов быстрее 300 мс, 5% медленнее. Среднее прячет хвост: при среднем 200 мс p99 может быть 4 секунды, и это тысячи медленных ответов в день. Поэтому SLO формулируют через p95 или p99.
Перцентили нельзя усреднять. Если четыре агента прислали свои p95, общий p95 это не их среднее: считают по объединённым данным или по сливаемым гистограммам.
Пользователи и RPS
Связь даёт закон Литтла: одновременно в системе = интенсивность × время. Для сценария:
RPS ≈ пользователи / (время ответа + пауза между действиями)
100 пользователей с ответом 0,5 с и паузой 4,5 с дают около 20 RPS.
Закрытая модель фиксирует число виртуальных пользователей: каждый ждёт ответа, потом шлёт следующий запрос. Если сервер замедлился, RPS сам падает, и деградация прячется. Открытая модель держит заданную интенсивность прихода запросов, как реальные посетители сайта, которые не ждут друг друга. В k6 это executor constant-arrival-rate или ramping-arrival-rate. Связанная ловушка закрытой модели называется coordinated omission: медленные периоды недопредставлены в замерах.
Инструменты
- JMeter: Java, план в GUI (
.jmx), Thread Group задаёт пользователей, ramp-up и длительность; запуск без GUI в CI. - k6: сценарии на JavaScript, движок на Go, пороги прямо в коде.
- Gatling: сценарии на Scala, Java или Kotlin, подробные HTML-отчёты.
- Locust: пользователи на Python.
- Яндекс.Танк: встречается в российских компаниях.
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 100 },
{ duration: '10m', target: 100 },
{ duration: '1m', target: 0 },
],
thresholds: {
http_req_duration: ['p(95)<500'],
http_req_failed: ['rate<0.01'],
},
};
export default function () {
const res = http.get(`${__ENV.BASE_URL}/api/products`);
check(res, { 'статус 200': (r) => r.status === 200 });
sleep(3);
}
Если порог не выполнен, k6 завершится с ненулевым кодом, и CI покажет провал.
Процесс
- Цели и критерии: ожидаемый пик, SLO по перцентилям и ошибкам.
- Профиль нагрузки: какие операции и в каких пропорциях, по логам и метрикам прода.
- Стенд, похожий на прод, данные реального объёма, мониторинг всего, включая генератор.
- Отладка скриптов на малой нагрузке.
- Серия тестов по плану.
- Анализ и отчёт с выводами и рекомендациями, повтор после исправлений.
Чтение результатов
- Предел виден там, где RPS перестаёт расти, а время ответа уходит вверх нелинейно или растут ошибки.
- CPU приложения 30%, а ответы медленные: запросы чего-то ждут. Ищите пул соединений к базе, блокировки, медленные запросы, внешние вызовы.
- Генератор загружен на 100%: результатам верить нельзя, нужно больше машин или легче сценарий.
- Маленькая база на стенде даёт отличные цифры, которые не переносятся на прод: запросы на миллионах строк ведут себя иначе.
Что спросят на собесе
- Какие виды нагрузочного тестирования вы знаете?
- Что такое перцентиль и почему не смотрят на среднее?
- Каким инструментом пользовались и как устроен сценарий?
- Как подготовить нагрузочный тест к распродаже?
- Как найти узкое место по результатам?