Нагрузочное тестирование сайта: когда оно нужно, что проверяют и как понять, выдержит ли сайт наплыв посетителей

Короткий ответ: нагрузочное тестирование — это проверка, как сайт ведёт себя, когда к нему одновременно обращается много людей. Оно нужно перед известным пиком: распродажей, крупной рассылкой, запуском рекламы, стартом сервиса или приёмом заявок к сроку. Сайту-визитке с ровным потоком посетителей оно обычно не нужно — там хватит мониторинга.

Что такое нагрузочное тестирование простыми словами?

Это имитация наплыва посетителей. Специальная программа запускает сотни или тысячи «виртуальных пользователей», которые проходят те же шаги, что и живые люди, а инженер смотрит, когда сайт начинает тормозить и ошибаться.

Виртуальный пользователь — это не человек и не браузер, а скрипт, который отправляет серверу те же запросы: открыть каталог, применить фильтр, положить товар в корзину, оформить заказ. Таких скриптов запускают столько, сколько нужно, и постепенно добавляют новых. Для этого используют открытые инструменты вроде k6, Apache JMeter или Locust, но выбор программы — самая простая часть работы. Сложнее и важнее правильно описать, что делают посетители, и честно прочитать результат.

От обычного тестирования нагрузочное отличается вопросом. Функциональная проверка отвечает «работает ли кнопка». Нагрузочная — «работает ли она, когда её одновременно нажимают пятьсот человек». Обзор всех видов проверок есть в статье «Тестирование сайта: какие проверки делает разработчик», здесь разбираем только нагрузку.

Когда нагрузочное тестирование действительно нужно?

Когда вы заранее знаете, что людей придёт заметно больше обычного, и цена сбоя высока. Признак простой: если сайт «ляжет» в этот день, вы потеряете деньги, которые потом не вернуть, — продажи акции, оплаченный рекламный трафик, заявки, принятые только до определённой даты.

Типичные ситуации:

• Распродажа или акция. Интернет-магазин объявляет скидки и пишет о них всей базе в одно время. Нагрузка приходится не на главную, а на каталог, фильтры, корзину и оплату — самые тяжёлые места.
• Крупная рекламная кампания. Реклама по всей стране, интеграция у блогера, упоминание на телевидении. Трафик приходит волной за минуты, а не равномерно за день.
• Запуск сервиса. Веб-приложение или личный кабинет, куда в день старта переводят всех клиентов сразу. Пользователи не просто смотрят страницы, а входят, загружают файлы, формируют отчёты.
• Приём заявок к сроку. Запись на курсы, приём документов, бронирование мест на мероприятие: большая часть людей приходит в первые минуты после открытия или в последний день.
• Рабочее утро в системе. CRM или кабинет, где в 9:00 одновременно входят все сотрудники и подрядчики, а в обед запускаются выгрузки.
• Тяжёлые фоновые операции. Импорт прайса на десятки тысяч позиций, синхронизация остатков с маркетплейсами, обмен с 1С — они нагружают ту же базу, с которой работают посетители.

Когда нагрузочный тест не нужен?

Если трафик ровный и небольшой, а пиков вы не планируете, тест почти ничего не даст. Лендингу, сайту компании на несколько страниц, блогу без тяжёлых фильтров хватит нормального хостинга, кэширования и мониторинга доступности.

Не тратьте деньги на нагрузочный тест, если:

• сайт отдаёт в основном статические страницы, а заявки уходят через простую форму;
• вы не можете назвать даже порядок ожидаемой нагрузки — сначала посмотрите статистику прошлых пиков;
• до пика осталось два дня и исправить найденное всё равно не успеют — полезнее подготовить запасной план;
• сайт уже тормозит у одного посетителя — сначала разберитесь со скоростью, об этом статья «Скорость загрузки сайта: как проверить и ускорить».

Правило соразмерности простое: стоимость подготовки должна быть меньше, чем потеря от часа простоя в пиковый день. Если сбой формы — это пара потерянных заявок, вкладываться в нагрузочный тест рано.

Вид теста	Как устроен	На какой вопрос отвечает
Дымовой (smoke)	Несколько виртуальных посетителей, пара минут	Работает ли сам сценарий теста и нет ли явных поломок до большого прогона
Обычная нагрузка	Плавный рост до ожидаемого числа посетителей, полка, спад	Держит ли сайт ваш обычный или прогнозный трафик с нормальным временем ответа
Стресс	Нагрузка выше прогноза: в полтора-два раза и больше	Что ломается первым, если пришло больше людей, чем рассчитывали, и восстанавливается ли сайт сам
Пик (spike)	Резкий скачок за секунды: рассылка, пуш, эфир	Переживёт ли сайт момент, когда все пришли одновременно по одной ссылке
Длительный (soak)	Обычная нагрузка несколько часов подряд	Не копятся ли утечки памяти, переполненные очереди и диск, которые проявляются только со временем
Поиск предела (breakpoint)	Нагрузка растёт ступенями, пока система не откажет	Какой запас у сайта сейчас и где узкое место

Какие бывают виды нагрузочных тестов?

Основных видов шесть: дымовой прогон, обычная нагрузка, стресс, резкий пик, длительный тест и поиск предела. Для подготовки к одному событию обычно хватает трёх: дымового, обычной нагрузки по прогнозу и пика или стресса.

Такое деление используют и разработчики инструментов: например, в документации k6 описаны те же типы — smoke, average-load, stress, soak, spike и breakpoint (Grafana k6, Load test types). Названия в отчётах подрядчиков могут отличаться, важно, на какой вопрос отвечает каждый прогон.

Для интернет-магазина перед распродажей разумный набор такой: дымовой прогон, чтобы убедиться, что сценарий корректен; обычная нагрузка по прогнозу пика; резкий скачок, имитирующий момент рассылки. Для сервиса, который будет работать весь день, к этому добавляют длительный прогон на несколько часов: часть проблем проявляется только со временем.

Как поставить цель теста?

Цель — это измеримое условие: «при N одновременных покупателях, которые проходят такой-то сценарий, 95 % страниц открываются быстрее X секунд, а ошибок меньше Y %». Без такой формулировки тест превращается в график, который нечем сравнить.

Цель собирают из трёх частей.

1. Сколько людей придёт. Возьмите статистику прошлых пиков из Яндекс Метрики или другой аналитики: максимальное число визитов за час, а не за день. Добавьте прогноз от новой рекламы или рассылки: размер базы, ожидаемую долю открытий, время отправки. Затем заложите запас — пик почти всегда выше прогноза.
2. Что они будут делать. Распишите сценарии с долями: например, 60 % смотрят каталог и уходят, 25 % пользуются фильтрами и поиском, 10 % кладут в корзину, 5 % оформляют заказ. Тест «тысяча человек открывают главную» почти ничего не говорит о том, выдержит ли оплата.
3. Что считать успехом. Договоритесь о допустимом времени ответа для ключевых шагов и допустимой доле ошибок. Для страницы оплаты планка жёстче, чем для страницы «О компании».

Хорошо, если цель записана до начала работ. Тогда и вы, и подрядчик понимаете, когда подготовка закончена, а отчёт превращается в ответ «да, выдержит с запасом» или «нет, упрёмся вот здесь».

Как проходит нагрузочное тестирование?

Работа состоит из пяти шагов: стенд, сценарии, прогоны, разбор узких мест и повторный прогон после исправлений. Сам запуск теста занимает часы, а подготовка и исправления — основное время.

1. Стенд. Тестируют на копии сайта, максимально похожей на рабочий: тот же сервер или такой же по мощности, та же база с реальным объёмом товаров и заказов. Тест на пустой базе даст красивые и бесполезные цифры. Как устроены тестовые серверы, мы разбирали в статье «Тестовый сервер, деплой и релиз простыми словами».
2. Сценарии. Скрипты повторяют шаги из цели: вход, каталог, фильтры, корзина, оформление. Внешние сервисы — оплату, отправку СМС, передачу заказов в CRM и 1С — на время теста подменяют заглушками, чтобы не создавать тысячи настоящих заказов и не нагружать чужие системы.
3. Прогоны. Начинают с дымового, затем постепенно поднимают нагрузку до целевой и выше. Во время прогона снимают показатели сервера и базы данных.
4. Разбор. Находят узкое место: медленный запрос к базе, фильтр без индекса, тяжёлую картинку без кэша, нехватку соединений, слабый сервер. Обычно оно одно-два, и их исправление даёт основной эффект.
5. Повторный прогон. После исправлений тест запускают снова и сравнивают с первым. Только повторный прогон подтверждает, что правка помогла, а не перенесла проблему в другое место.

Метрика	Что означает	Как читать заказчику
Запросов в секунду (RPS)	Сколько обращений к серверу сайт обрабатывает каждую секунду	Сравнивайте не с «красивым числом», а с вашим прогнозом пика, пересчитанным в запросы
Одновременные пользователи	Сколько виртуальных посетителей одновременно проходят сценарий	Важно, какой сценарий они проходят: просмотр главной и оформление заказа нагружают сайт по-разному
Время ответа: медиана и 95-й процентиль	Половина запросов быстрее медианы; 95 % — быстрее значения p95	Смотрите на p95: среднее прячет тех, кто ждал по 10 секунд и ушёл
Доля ошибок	Сколько запросов закончилось ошибкой сервера или таймаутом	На целевой нагрузке ошибок быть почти не должно; любая ошибка в оплате — повод разбираться
Загрузка сервера и базы	Процессор, память, диск, соединения с базой данных во время теста	Показывает узкое место: куда вкладываться — в код, базу или сервер
Точка деградации	Нагрузка, при которой время ответа или ошибки резко пошли вверх	Это ваш реальный потолок; запас до него и есть ответ «выдержит ли»

Какие метрики должны быть в отчёте?

Минимум — запросы в секунду, число одновременных пользователей, время ответа (медиана и 95-й процентиль), доля ошибок и загрузка сервера. И главное — вывод: выдержит ли сайт целевую нагрузку и какой у него запас.

Отчёт без вывода — просто набор графиков. Попросите подрядчика ответить на три вопроса человеческим языком: какую нагрузку сайт выдерживает сейчас, что сломалось первым при превышении и что сделали или предлагают сделать. Если в отчёте только «средний ответ 300 мс», уточните p95 и долю ошибок на пике — средние цифры часто выглядят спокойно, когда часть посетителей уже получает ошибки.

Что обычно ломается под нагрузкой?

Чаще всего узким местом оказывается не сервер целиком, а одно конкретное место: база данных, тяжёлый фильтр, поиск, внешний сервис или очередь фоновых задач. Поэтому «просто купить сервер мощнее» помогает не всегда.

• База данных. Запросы, которые незаметны на десяти посетителях, на тысяче выстраиваются в очередь. Помогают индексы, переписанные запросы, кэш результатов.
• Фильтры и поиск в каталоге. Подсчёт количества товаров по каждому фильтру на лету — частая причина тормозов в магазинах.
• Внешние сервисы. Платёжная страница, расчёт доставки, проверка остатков в 1С: если сайт ждёт их ответа синхронно, медленный внешний сервис тормозит всех посетителей.
• Отсутствие кэша. Страницы, которые одинаковы для всех посетителей, каждый раз собираются заново.
• Лимиты хостинга. Ограничения тарифа хостинга на число процессов, соединений или трафика, о которых вспоминают только в пиковый день.
• Фоновые задачи. Импорт прайса или рассылка, запущенные в момент пика, отнимают ресурсы у покупателей.

Как подготовиться к пиковому дню?

Кроме самого теста нужен план на день пика: заморозка изменений, перенос тяжёлых задач, усиленный мониторинг, понятный порядок действий при сбое и запасная страница. Это дешевле теста и полезно в любом случае.

• Заморозка релизов. За несколько дней до пика не выкладывайте новые функции, только исправления критичных ошибок.
• Фоновые операции — на ночь. Импорт, выгрузки, синхронизации переносят с часов пика.
• Рассылку — порциями. Если база большая, отправка частями растягивает волну посетителей и снимает самый острый пик.
• Мониторинг и ответственные. Уведомления о падении и росте ошибок приходят конкретным людям, которые в этот день на связи. Что именно отслеживать, описано в статье «Мониторинг сайта после запуска».
• Запасной план. Заранее подготовленная страница «Мы перегружены, оставьте телефон — перезвоним», быстрый способ отключить тяжёлые блоки, понятный порядок, кто и что делает при сбое.
• Предупредите хостинг. Если ждёте трафик заметно выше обычного, обсудите с провайдером лимиты тарифа и возможность временно добавить ресурсы.

Какие ошибки встречаются чаще всего?

Главные ошибки — тест не тех сценариев, тест на пустой базе, тест накануне пика и запуск нагрузки на рабочий сайт без предупреждения. Все они дают либо ложное спокойствие, либо реальный сбой.

• Нагружают только главную. Она обычно хорошо кэшируется, и тест показывает отличные цифры, а падает корзина.
• Пустая или маленькая база. Запросы к базе с сотней товаров и с сотней тысяч ведут себя совершенно по-разному.
• Реальные оплаты и рассылки в тесте. Тысячи тестовых заказов в CRM, письма клиентам, СМС за ваш счёт.
• Нагрузка на боевой сайт в рабочее время. Тест сам устраивает тот сбой, от которого должен был защитить. Защита хостинга от атак может принять такой тест за атаку и заблокировать адреса.
• Тест без повторного прогона. Исправили, но не проверили — и узнали о результате в день распродажи.
• Ставка только на мощный сервер. Если узкое место — медленный запрос, более дорогой тариф отодвинет проблему ненадолго.

Чек-лист заказчика перед нагрузочным тестом

Перед стартом работ у вас должны быть ответы на восемь вопросов ниже. Они экономят время подрядчика и делают отчёт понятным для вас.

1. Какое событие ожидается, дата и время начала?
2. Сколько посетителей было в прошлый пик за самый нагруженный час?
3. Какой прогноз: размер базы для рассылки, охват рекламы, ожидаемая доля переходов?
4. Какие три-пять сценариев важнее всего: что люди будут делать на сайте?
5. Какое время ответа и какая доля ошибок для вас допустимы на ключевых шагах?
6. Где проводим тест: копия сайта или рабочий сайт в согласованное ночное окно?
7. Какие внешние сервисы подменяем заглушками: оплата, СМС, CRM, 1С, доставка?
8. Сколько времени остаётся на исправления и повторный прогон?

Как это устроено в работе Roboweb.team?

Нагрузочное тестирование не входит в базовые тарифы отдельной строкой: большинству сайтов оно не нужно. Если вы ждёте пик, мы разбираем задачу, говорим, нужен ли тест, и называем цену и срок до старта.

Для проектов, которые мы разрабатываем, подготовка обычно выглядит так: оцениваем прогноз вместе с вами, гоняем сценарии на тестовом сервере, исправляем найденные узкие места в коде и базе, повторяем прогон и даём короткий отчёт с выводом. Для проектов на поддержке (от 7 900 ₽ в месяц) подготовку к распродаже или запуску берём по абонентке или разово как отдельную задачу. Если ошибка в нашей работе проявилась после сдачи, её исправляем бесплатно в рамках гарантии — 30 календарных дней с даты подписания акта. Как мы ведём заказную разработку целиком, рассказано на странице «Заказная разработка под ключ».

Короткие ответы на частые вопросы

Сколько посетителей выдержит мой сайт?

Без измерения ответа нет: число зависит от сценария, кода, базы данных и сервера. Один и тот же сайт может спокойно отдавать тысячи просмотров страниц в минуту и при этом «лечь» от сотни одновременных оформлений заказа. Нагрузочный тест как раз и находит этот потолок для ваших сценариев.

Можно ли проводить нагрузочный тест на рабочем сайте?

Можно, но только в согласованное окно с минимальным трафиком, с предупреждением хостинга и с отключёнными реальными оплатами, рассылками и передачей заказов в CRM. Надёжнее гонять тест на копии сайта с тем же сервером и теми же данными.

Чем нагрузочное тестирование отличается от проверки скорости?

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

Сколько стоит нагрузочное тестирование?

Отдельной строки в нашем прайсе нет: объём зависит от числа сценариев, стенда и того, нужно ли сразу исправлять найденное. Цену и срок называем после разбора задачи и до старта работ. Для проектов на поддержке (от 7 900 ₽ в месяц) подготовку к пику берём по абонентке или разово как отдельную задачу.

Как часто нужно повторять нагрузочный тест?

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

Услуги и кейсы по теме: заказная разработка · типовые договоры · цены и сроки