Нагрузочный тест на k6

«Учебный стенд должен выдержать 100 итераций в секунду с долями 80/15/5; p95 меньше 500 мс, доля отказов ниже 1%». Попросите расписание разгона, стабильного участка и завершения. Числа являются условиями примера, а не нормой для любого сервиса. Уточните, сколько HTTP-запросов содержит итерация: иначе ожидаемые итерации и фактический RPS окажутся разными величинами.

Число виртуальных пользователей определяет параллельное выполнение сценариев, а скорость зависит от ответов и пауз. При замедлении системы закрытая модель может сама снизить интенсивность. Если нужно заданное поступление операций, выбирайте соответствующую модель и контролируйте нехватку исполнителей. Попросите объяснить различие на медленном ответе, чтобы тест не выглядел успешным только потому, что перестал подавать запланированную нагрузку.

Проверки содержимого и пороги итоговых метрик решают разные задачи. Чтобы выбранное условие влияло на результат прогона, его нужно связать с согласованным критерием. Попросите тестовый ответ с ошибочным телом при HTTP 200 и покажите, какой показатель обнаружит проблему. Быстрые неправильные ответы не должны улучшать итоговую оценку производительности сервиса и проходить приёмку по одной задержке.

Используйте выделенный стенд, синтетические записи и отключённые внешние отправки. Подготовка справочников не должна случайно попадать в измеряемый участок, если не является частью сценария. Задайте очистку и пределы запуска. Енотик подготавливает сценарий, но не генерирует нагрузку автоматически; разрешение среды, фактический прогон и оценка влияния на соседние системы остаются частью вашей процедуры тестирования.