Нагрузочное тестирование через прокси: безопасный план с k6
Нагрузочный тест допустим только для принадлежащей вам системы или при явном разрешении владельца. Мобильный канал имеет собственную ёмкость и не должен использоваться как бесконечный генератор трафика.
Главное за минуту
- Сначала smoke, затем базовая нагрузка и только потом тяжёлые профили.
- Порог превращает ожидание в проверяемый критерий.
- Каждая ступень нагрузки имеет собственное стоп-условие.
- Насыщение прокси нельзя выдавать за предел целевого приложения.
Разрешение и окно
Запишите цели, максимальный RPS или VU, длительность, стоп-условия и ответственных. Для production согласуйте период и план быстрого прекращения.
Scope должен содержать точные hosts, endpoints, тестовые аккаунты, верхний предел RPS/VU, общий объём трафика и запрет на зависимые сторонние сервисы. Назначьте наблюдателя со средствами немедленной остановки и канал связи с владельцем системы. Если параметры или разрешение не подтверждены, ограничьтесь одиночным smoke-запросом либо перенесите проверку на изолированный стенд.
Профиль нагрузки
Smoke выявляет ошибки сценария, average-load создаёт базовую линию, stress ищет предел, spike моделирует скачок, soak проверяет длительную стабильность.
Переходите между ступенями только после проверки предыдущей: одна итерация, 1 VU, малый canary, целевая средняя нагрузка и отдельный согласованный stress. На каждой ступени сравнивайте error rate, p95 и ресурсы с базовой линией. Автоматически прекращайте рост при заранее заданной доле ошибок, насыщении прокси или признаках деградации соседних сервисов.
Пороги
Задайте долю ошибок и перцентили времени ответа для важных endpoints. Не полагайтесь только на среднее значение, которое скрывает медленный хвост.
Для критичных операций задайте отдельные thresholds: например, доля ошибок, p90/p95/p99 и минимум успешных бизнес-транзакций. Порог должен учитывать холодный старт и согласованное окно, но не расширяться после неудачи ради зелёного отчёта. Публикуйте фактический профиль нагрузки вместе с результатом, иначе цифры нельзя воспроизвести или сравнить между версиями.
Сетевой предел
Отдельно наблюдайте прокси, мобильный канал и целевой сервис. Иначе насыщение одного промежуточного участка ошибочно примут за предел приложения.
Измеряйте загрузку генератора, очередь прокси, открытые соединения, мобильный канал и ресурсы приложения одновременно. Если генератор или маршрут достиг предела первым, зафиксируйте тест как инфраструктурно ограниченный и не объявляйте пределом приложения. Не распределяйте трафик по большому числу выходов для обхода ограничений цели: это выходит за рамки безопасного тестирования.
Практический чек-лист
- 1Получите письменный scope.
- 2Начните с одной итерации.
- 3Настройте аварийную остановку.
- 4Зафиксируйте максимум RPS/VU и объём трафика.
- 5Публикуйте профиль нагрузки с отчётом.
Источники и документы
Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.