Как вы подходите к нагрузочному тестированию? Какие виды нагрузки и метрики используете?
Короткий ответ
- Сначала цели и профиль нагрузки, потом скрипты
- Виды: load, stress, spike, soak на выносливость
- Метрики: перцентили времени ответа, RPS, ошибки, ресурсы
- Смотрю p95/p99, а не среднее
- Инструменты: k6, JMeter, Gatling, Locust
- Стенд и данные должны быть похожи на прод
- Результат — отчёт с узким местом и рекомендацией
Нагрузочное тестирование — это проверка системы против целевого профиля нагрузки с анализом перцентилей, ошибок и узких мест.
Как сказать вслух
пример ответаНачинаю не со скриптов, а с целей: какая ожидается нагрузка, какие сценарии самые массовые, какие требования к времени ответа. Потом строю профиль и пишу сценарии, например на k6 или JMeter. Виды тестов разные: обычная нагрузка по профилю, стресс до отказа, резкий скачок и длительный тест на утечки. Смотрю перцентили времени ответа, пропускную способность, процент ошибок и ресурсы серверов. На выходе — отчёт: где узкое место и что с ним делать.
Подробный ответ
Основной ответ
Нагрузочное тестирование начинается с нефункциональных требований: целевой RPS или число одновременных пользователей, SLA по времени ответа (например, p95 < 500 мс), допустимый процент ошибок. Из аналитики прода строится профиль нагрузки — какие операции и в какой пропорции выполняют пользователи. Виды тестов: load — проверка на целевом профиле; stress — ступенчатое повышение до деградации, чтобы узнать запас прочности и характер отказа; spike — резкий скачок (распродажа, рассылка); soak/endurance — многочасовая умеренная нагрузка для поиска утечек памяти и деградации. Ключевые метрики: перцентили времени ответа (p50, p95, p99 — среднее скрывает проблемы), throughput, error rate, насыщение ресурсов (CPU, память, соединения БД, очереди). Инструменты: k6 (сценарии на JavaScript, удобен в CI), JMeter, Gatling, Locust. Важные условия честного теста: стенд, сопоставимый с продом, прогрев, реалистичные данные, генераторы нагрузки не упираются в собственные ресурсы.
Ключевые моменты
- Перцентили вместо среднего. Среднее 200 мс может скрывать p99 в 5 секунд — а это сотни недовольных пользователей.
- Профиль из прода. Нагрузка строится из реальной пропорции операций, иначе тест проверяет несуществующий сценарий.
- Разные вопросы — разные тесты. Load отвечает «тянем ли план», stress — «где предел», soak — «не течём ли со временем».
- Критерии прохождения заранее. Пороги по времени ответа и ошибкам фиксируются до запуска, например thresholds в k6.
Практический контекст
У мидлов проверяют понимание методологии, а не знание кнопок JMeter: с чего начать, чем отличаются виды нагрузки, почему среднее время — плохая метрика. Частый практический вопрос: «нам нужно выдержать 1000 пользователей — как проверите?» Ожидается уточнение: одновременных или в сутки, какой сценарий, какое допустимое время ответа — само уточнение уже показывает зрелость.
Пример кода
// k6: нагрузка со ступенями и порогами
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 100 }, // разгон
{ duration: '5m', target: 100 }, // полка
{ duration: '1m', target: 0 }, // спад
],
thresholds: {
http_req_duration: ['p(95)<500'], // SLA: p95 < 500 мс
http_req_failed: ['rate<0.01'], // ошибок < 1%
},
};
export default function () {
const res = http.get('https://test.example.com/api/products');
check(res, { 'status 200': (r) => r.status === 200 });
sleep(1);
}Частые ошибки
- Оперируют средним временем ответа и не знают про перцентили
- Начинают со скриптов, не сформулировав цели и профиль нагрузки
- Гоняют нагрузку на стенде, в разы слабее прода, и переносят выводы напрямую