Нагрузочное тестирование сайта перед рекламой или распродажей: план и критерии
Нагрузочное тестирование сайта показывает, как выбранные действия работают при заданном потоке обращений и где перестают выполняться согласованные требования. Перед рекламой или распродажей полезно проверять путь к заказу или заявке: успешность, задержку, состояние очередей и способность системы вернуться к обычной работе после пика.
Вопрос «сколько посетителей выдержит сайт» требует уточнений. Человек, который читает страницу, создаёт другую нагрузку, чем покупатель, многократно меняющий фильтры и условия доставки. Поэтому результат испытания должен описывать профиль действий, интенсивность, длительность и критерии качества. Одно число без этих условий мало помогает планировать кампанию.
Ниже — план подготовки и оценки такого испытания. Все числа в примерах условные. Тестируют собственную согласованную инфраструктуру; работа внешних сервисов, тестовые данные и пределы воздействия заранее включаются в план. Статья описывает подготовку, а не запускает нагрузку.
Какую задачу поставить перед испытанием
Начните с конкретного решения: готов ли сайт к ожидаемому потоку, требуется ли ограничить запуск рекламы или какой участок нужно исправить до распродажи. Для каждой задачи определите проверяемое действие и приемлемый результат. «Выдерживает много людей» замените формулировкой с наблюдаемыми условиями.
Пример цели: при прогнозируемом поступлении новых сеансов каталог отвечает в согласованных пределах, тестовые заказы корректно сохраняются, фоновая обработка не накапливает недопустимое отставание. Отдельно укажите, как долго нужно удерживать нагрузку. Короткий всплеск и несколько часов распродажи проверяют разные риски.
В руководстве k6 по нагрузочному тестированию сайтов различаются проверки на уровне протокола, браузера и их сочетания. HTTP-сценарий удобен для нагрузки на обработку запросов, но сам по себе не подтверждает работоспособность кнопок и JavaScript. Несколько браузерных проходов могут дополнить его наблюдением за интерфейсом.
Результат первого испытания может состоять в обнаружении ошибки самого сценария или неподготовленного окружения. Это полезный вывод, но он ещё не характеризует ёмкость сайта. Сначала нужно подтвердить, что инструмент действительно создаёт нужную работу и правильно оценивает её результат.
Как перевести рекламный прогноз в модель нагрузки
Соберите ожидаемые начала сеансов по времени, добавив обычный трафик к кампании. Суточного числа посещений недостаточно: рассылка или ограниченная акция способны создать короткий концентрированный поток. Используйте доступные наблюдения прошлых запусков и явные допущения, если подходящей истории нет.
Рекламные клики, посетители и сеансы не тождественны. Один человек может вернуться, открыть несколько вкладок или не дождаться загрузки. Запишите, что именно считает прогноз. Для учебного примера предположим, что ожидаются 7 200 начал сеансов в час суммарно из всех источников и внутри выбранного часа поток равномерный.
Это 7 200 / 3 600 = 2 новых сеанса в секунду. Допустим, сценарии распределены следующим образом; паузы чтения уже входят в длительность:
| Сценарий | Доля начал | Динамических HTTP-запросов | Средняя длительность |
|---|---|---|---|
| Просмотр карточек | 70% | 4 | 60 секунд |
| Поиск и фильтры | 20% | 8 | 120 секунд |
| Тестовое оформление | 10% | 16 | 240 секунд |
Среднее число выбранных запросов равно 0,7 × 4 + 0,2 × 8 + 0,1 × 16 = 6. Ожидаемая интенсивность — около 2 × 6 = 12 HTTP-запросов в секунду. Средняя длительность сеанса составляет 90 секунд; при устойчивом потоке одновременно активны в среднем около 2 × 90 = 180 сеансов.
Расчёт предполагает выполнение заданного профиля без дополнительных повторов и изменения длительностей. Он не включает картинки и другие ресурсы, отсутствующие в модели. Это ориентир для настройки, а не оценка всех браузерных запросов и не точное число уникальных людей на сайте.
Чем VU, iterations/s и HTTP RPS отличаются друг от друга
Виртуальный пользователь, VU, — исполнитель сценария в генераторе. Итерация — один запуск этого сценария. HTTP RPS — количество HTTP-запросов в секунду. Итерация может содержать один запрос, несколько переходов, проверки результата и паузы; поэтому эти единицы нельзя заменять друг другом.
В нашем примере одна итерация моделирует один сеанс. Значение 2 iterations/s означает два новых запуска сеансов в секунду. При среднем составе в шесть запросов это соответствует примерно 12 HTTP RPS после выхода на устойчивый режим. Нельзя написать «200 VU = 200 посетителей в секунду»: количество исполнителей не задаёт такое поступление.
k6 различает закрытую модель и открытую модель arrival rate. В закрытой модели следующий проход конкретного VU ждёт завершения предыдущего. В открытой задаётся темп старта итераций, независимый от их завершения, при наличии ресурсов для запуска.
Например, 180 постоянно занятых VU при средней итерации 90 секунд дают приблизительно 2 итерации в секунду. Если из-за замедления длительность вырастет до 120 секунд, закрытая модель даст около 1,5 итерации в секунду. Нагрузка начнёт уменьшаться вместе с ухудшением ответа, хотя реальный рекламный поток может продолжать приходить.
Для сохранения открытого потока в 2 итерации в секунду при длительности 120 секунд нужно в среднем около 240 занятых исполнителей, плюс запас на изменчивость. Это оценка потребности, а не команда бесконтрольно добавлять VU: верхние границы ресурсов и воздействия должны оставаться согласованными.
Как выбрать реалистичные сценарии
Возьмите несколько действий, которые определяют результат кампании: посадочная страница, карточка, поиск, корзина, расчёт доставки и создание тестовой заявки. Зафиксируйте доли, последовательность и паузы. Различайте чтение и запись: многократное открытие закешированной главной почти ничего не говорит о конкурентном создании заказов.
Подготовьте разнообразные тестовые объекты. Если все обращения используют один товар и один поисковый запрос, кеш может сделать испытание слишком лёгким. Если все VU изменяют одну корзину, ошибки будут вызваны искусственным конфликтом данных. Состояние каждого сценария должно соответствовать моделируемому поведению.
Отдельно опишите авторизацию, кеш, повторные обращения и лимиты. Нельзя автоматически исключать защитный слой или кеширование и затем объявлять результат характеристикой обычного пользовательского пути. Если проверяется отдельный компонент, так и укажите в плане и отчёте.
Для редкого, но важного действия нужен достаточный объём наблюдений. При доле оформления 10% и коротком прогоне его P99 будет опираться на существенно меньшую выборку, чем показатель каталога. Продолжительность испытания выбирают с учётом таких сценариев, а не только общего числа запросов.
Проверьте, какое состояние начинает новую итерацию. Если модель описывает нового посетителя, ему не должны случайно достаться корзина и права предыдущего тестового сеанса. Если моделируются возвращающиеся покупатели, наоборот, подготовьте соответствующие аккаунты и историю. Само переиспользование исполнителя генератора не определяет бизнес-смысл пользователя: этот смысл задают данные и последовательность сценария.
Как подготовить окружение и исключить реальные операции
Первый прогон выполняйте на подходящем стенде с известными различиями относительно production. Зафиксируйте мощности, версии, объём данных, настройки кеша и интеграций. Если стенд существенно слабее рабочего окружения, результат покажет его ограничения; переносить измеренное число на production пропорцией без проверки нельзя.
Тестовые заказы должны оставаться тестовыми. Используйте отдельные данные и получателей, остановите нежелательные рассылки и исключите реальные платежи, отгрузки и изменения клиентских записей. Проверьте фоновые процессы: последствия могут появиться спустя время после завершения HTTP-запроса.
Для внешнего API согласуйте допустимые условия с его владельцем либо применяйте предназначенную песочницу или управляемую заглушку. Песочница тоже может иметь ограничения нагрузки. Если партнёр заменён заглушкой, измеряется работа вашей системы с заданным поведением зависимости, а не производительность самого партнёра.
Генератор размещайте так, чтобы он не отбирал ресурсы у проверяемого приложения и не скрывал сетевую границу, которую требуется измерить. Испытание рабочего сайта, если оно необходимо, планируют отдельно: окно, пределы, ответственные и остановка должны учитывать настоящих посетителей.
Какие критерии задать до запуска
Успешный HTTP 200 может содержать страницу ошибки, пустой результат поиска или неподтверждённый заказ. Проверяйте смысл ответа: нужные поля, идентификатор операции и соответствующее состояние. Для асинхронной обработки отдельно определите допустимое время получения результата.
В документации k6 о checks описаны проверки логических условий. Неуспешная проверка сама по себе не останавливает тест и не делает итоговый статус неуспешным. Для итоговой оценки используют правила по метрикам; необходимую реакцию на нарушение настраивают явно.
Пример критериев ниже относится к условному проекту. Значения не являются нормативом для всех сайтов; команда согласует их по важности операции и требованиям к своему сервису.
| Область | Учебный критерий | Как трактовать |
|---|---|---|
| Бизнес-результат | Не менее 99,5% начатых тестовых оформлений завершились правильно в заданный срок | Неуспешные и не завершившиеся в срок попытки не исключаются из подсчёта |
| Ответ API заказа | P95 не больше 800 мс, P99 не больше 1 500 мс | Длительность выбранного HTTP-шага, отдельно от пауз и полного сеанса |
| Достигнутая нагрузка | Запланированный темп стартов подтверждён, пропусков запуска нет | Проверено фактическое воздействие, а не только настройки |
| Фоновая работа | Возраст задач остаётся в согласованной границе и после пика возвращается к обычному уровню | Быстрый ответ не скрывает накопление необработанных операций |
Thresholds в k6 задают условия успешности теста по метрикам. Итоговый провал критерия и немедленная остановка — разные настройки; для досрочного прекращения предусмотрено отдельное поведение. Общая доля успешных checks также не равна доле успешных заказов, если на каждый шаг приходится разное число проверок. Бизнес-результат учитывайте отдельным понятным показателем.
За какими показателями наблюдать одновременно
Снаружи нужны заданные и фактические начала сценариев, число запросов, ошибки, длительности и семантический успех. Рассчитывайте P95 и P99 отдельно по сценарию или однотипной операции и по выбранным интервалам нагрузки. Итоговое значение за весь прогон способно смешать спокойный старт с проблемной последней ступенью.
Перцентили разных маршрутов, генераторов и временных окон не усредняют. Для объединённого результата нужны исходные измерения или совместимые распределения. Рядом показывайте объём выборки; при малом числе операций высокий перцентиль не даёт устойчивой характеристики хвоста.
В справочнике метрик k6 указано, что http_req_duration включает отправку, ожидание и получение ответа, но не начальные DNS-поиск и установление соединения. Поэтому подпишите границы выбранного таймера. Полная длительность пользовательского действия и время одного HTTP-запроса — разные наблюдения.
Внутри системы смотрите CPU, память, соединения, ожидание базы, ошибки приложения, очереди и задержку зависимостей. Сам по себе свободный процессор не доказывает наличие запаса: приложение может ждать ограниченного пула соединений. Отметьте время начала каждой ступени, чтобы сопоставлять симптомы с воздействием.
Как убедиться, что ограничение не в генераторе
Генератору нужны собственные CPU, память и сеть. Следите за его состоянием, фактическим темпом стартов и незапущенными итерациями. Если инструмент перестал создавать предусмотренную работу, низкая нагрузка на сервер не доказывает, что сервер выдержал заявленный уровень.
Документация k6 по выделению VU для arrival rate объясняет необходимость доступного исполнителя для каждого старта. При недостатке VU возникают dropped_iterations. Причиной может быть как слишком маленький выделенный запас, так и выросшая длительность сценариев из-за замедления проверяемой системы.
Разбирайте это сочетание по данным. Если занято всё доступное число VU и длительность выросла, выясните, где накопилось ожидание. Если сам генератор перегружен, сначала устраните ограничение измерительного инструмента. Не увеличивайте его параметры без повторной оценки согласованного воздействия и доступных ресурсов.
При нескольких генераторах проверьте общий суммарный поток, различимость тестовых данных и единое время. Значение, указанное отдельно на каждом узле, может оказаться частью суммарного плана или случайно умножить его. Эта проверка нужна до перехода к следующим ступеням.
Убедитесь также, что запросы проходят ожидаемый маршрут. Например, защитный слой может возвращать страницу проверки вместо каталога, а перенаправление — отправлять сценарий в другое окружение. Большое число быстрых ответов в таком случае показывает обработку другого потока. Сверьте содержимое ответа и появление согласованных тестовых событий в нужном приложении, сохраняя установленные ограничения испытания.
План поэтапного испытания
Сначала выполните малый проверочный прогон: убедитесь в правильности маршрутов, данных, счётчиков и отсутствия настоящих внешних операций. Затем увеличивайте поток ступенями, оставляя время на стабилизацию. Новую ступень начинают после оценки предыдущей, а не только по расписанию.
| Этап | Задача | Условие продолжения |
|---|---|---|
| Проверка сценария | Несколько контролируемых запусков каждого пути | Результаты верны, побочные действия изолированы |
| Исходный уровень | Небольшая нагрузка и фиксация обычных показателей | Генератор и наблюдение работают корректно |
| Ожидаемый поток | Проверка модели кампании с согласованной длительностью | Выполняются критерии всех важных сценариев |
| Проверка запаса | Разрешённое постепенное повышение выше прогноза | Нет условия остановки, фактический поток подтверждён |
| Снижение и восстановление | Завершение стартов и наблюдение за оставшейся работой | Учтены активные операции, очереди и остаточные изменения |
Продолжительность должна позволять проявиться важным процессам: росту очереди, обновлению кеша или перераспределению ресурсов. Универсального «достаточно десяти минут» нет. Для проверки длительного пика нужен отдельный достаточно продолжительный участок в пределах согласованного плана.
При завершении различайте прекращение новых стартов и окончание уже начатых сценариев. Учтите максимальную длительность операций и предусмотренное прекращение зависших попыток. Остановка программы генератора не отменяет задачи, уже принятые приложением.
Когда прекращать увеличение нагрузки
Перед запуском назначьте человека, который может остановить испытание, и определите наблюдаемые основания. Если появились реальные письма, платежи или изменения клиентских данных, прекращайте новые действия и разбирайте последствия по согласованному порядку. Такой дефект изоляции не требует ожидания статистического порога.
Технические условия остановки могут включать устойчивое нарушение критерия ошибок, недопустимый рост задержки, опасное исчерпание ресурса или потерю наблюдения. Укажите окно оценки и предел длительности. Иначе краткий всплеск и продолжающаяся деградация будут трактоваться произвольно.
После остановки подтвердите, что сайт и зависимости вернулись в приемлемое состояние. Сверьте тестовые операции и очереди, сохраните журналы и результаты. Не удаляйте накопленные задания автоматически ради красивого графика: сначала определите их назначение и безопасную процедуру очистки.
Как описать измеренный уровень и запас перед кампанией
Предположим, учебный прогон подтвердил выполнение критериев при 2 и 3 началах сценария в секунду, а на следующей ступени 3,5 возникло нарушение согласованного времени ответа. Фактический поток на каждой ступени проверен; состав сценариев не менялся.
Корректный вывод: уровень 3 старта в секунду подтверждён для указанного окружения, профиля и длительности; на уровне 3,5 критерий не выполнен. По отношению к прогнозу 2 это измеренный запас 3 / 2 = 1,5, или 50% по интенсивности начал. Он не означает гарантию для любого трафика, более длинного пика или другой версии приложения.
Не объявляйте число 3 точным физическим пределом сайта. Между ступенями остался непроверенный диапазон, а причина нарушения могла зависеть от состояния данных или накопленного эффекта. Если критерии выполнились на всех разрешённых уровнях, предел вообще не найден: подтверждён только наибольший испытанный уровень.
В отчёте сохраните цель, версию, ресурсы, сценарии, данные, длительность ступеней, заданный и фактический поток, критерии, результаты и ограничения. Отдельно перечислите действия до кампании и что нужно перепроверить после исправлений. Такой документ позволяет принять решение о запуске и повторить измерение в сопоставимых условиях.
При повторном испытании меняйте условия осознанно. Если одновременно заменены сервер, сценарии и набор товаров, улучшение нельзя уверенно приписать одному исправлению. Сначала повторите исходный профиль, затем проверяйте дополнительные предположения. Сохраните сведения о прогреве кеша и фоновых работах: они помогают объяснить расхождения между двумя внешне одинаковыми прогонами.
Подключите SiteGuard для внешнего HTTP-контроля доступности сайта во время согласованного испытания. Генератор нагрузки, серверные метрики и проверку бизнес-результатов используйте отдельно.