Всем привет! 👋
В предыдущем посте мы с вами запустили простенький сценарий по нагрузочному тестированию.
У всех всё получилось? Пишите ваши результаты в комментариях!
🔍 Разбираем отчёт k6: что это вообще значит?
Ок, вы запустили базовый сценарий, получили красивый отчёт… и зависли. Я, например, в свое время точно завис.
Что означают все эти avg, p(95), iterations, vus?
Давайте разберёмся - без лишней теории, только практический смысл.
Отчет стартует со слов TOTAL RESULTS
✅ Checks - это как такие мини аналог ассертов, которые есть в Postman, и фреймворках автоматизации.
В нашем скрипте одна проверка - на status code 200.
checks_total: сколько всего проверок было за весь прогон.
checks_succeeded: сколько из них прошли успешно, то есть вернулся на наш запрос status code=200.
checks_failed: соответственно, сколько наших проверок провалилось.
✓ Подобные проверки дают нам понять насколько стабильно наша система работает под нагрузкой. Если с увеличением нагрузки checks_failed начинает тоже увеличиваться - вероятно у нас есть где-то проблемы.
🌐 HTTP - скорость и стабильность отклика
http_req_duration: время отклика сервера на наш запрос. Всем известно чем быстрей тем лучше! Никто не любит, когда после нажатия на кнопку приложение еще 10 секунд думает.
Здесь главное понимать, что тут по сути нет какого-то золотого стандарта.
Всё зависит от системы, от архитектуры, от операции, которые выполняются при вызове энд-поинта.
Пробежимся вкратце по сокращениям
avg - средняя температура по палате.
med - медиана, надежнее чем средняя, точнее устойчивее к "случайным" всплескам, которые могут быть.
p(90) / p(95) - процентили по времени отклика. Например, если указано как на скриншоте p(90)=2.69s, p(95)=2.69s, это означает, что 90% и 95% запросов были быстрее 2.69s.
http_req_failed: процент ошибок. → 0.00% — всё стабильно. это встроенная метрика, которая фиксирует любую неудачу при выполнении HTTP‑запроса. "Неудача" - это может быть таймаут, сетевая какая-нибудь ошибка, либо status code который не соответствует ожидаемому (по умолчанию k6 считает успешными 2хх и 3хх статус коды)
http_reqs: сколько всего запросов было отправлено во время нашего запуска. метрика показывает интенсивность нагрузки. То есть по этому показателю ты можешь понять корректно ли настроен твой сценарий. Если ты моделируешь работу 5 сотрудников, которые каждые 10 секунд проходят какой-то сценарий, то ты можешь высчитать сколько примерно запросов должно быть за время твоего теста. Если цифра сильно отличается, то значит надо корректировать либо vus, duration, либо саму логику сценария.
🔁 Execution — как отрабатывали VU
iterations: сколько всего итераций было выполнено.
iteration_duration: сколько длилась одна итерация. → Если итерации по 1.3 сек, а тест длился 5 сек — всё нормально, они шли параллельно: у нас 5 виртуальных пользователя, одна итерация в среднем 1,3 → то есть один пользователь за 5 секунд успевает выполнить (5/1.3=3.8) почти 4 итерации, всего у нас 5 VU, 5*4=20 - всё сходится.
vus_max = 5: сколько максимум виртуальных пользователей мы запускаем.
vus = 5: значит на протяжении всего теста всегда было ровно 5 активных VU. Никогда не было меньше, никогда не было больше. Что соответствует нашему сценарию. Если бы у нас был сценарий с нарастающей или переменной нагрузкой, где количество VU могло меняться в процессе теста, то значение было бы другим.
📡 Network - объём данных
data_received / data_sent: сколько данных было получено / передано. → Полезно понимать, если API гоняет большие payload'ы.
🎯 И это всё что нужно?
Это базовые метрики, которые уже идут по умолчанию из коробки k6.
Конечно, на практике используют дополнительные метрики, которые подбираются индивидуально под бизнес-логику и цели нагрузки.
Если было интересно и полезно - поддержи реакцией! 🔥
🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman
