Нагрузочное тестирование сайта перед запуском
Нагрузочный тест отвечает на вопрос, сколько посетителей выдержит сайт на выбранном сервере и что сломается первым. Его проводят на собственном сервере и только на нём: генератор нагрузки — отдельная машина, хостер предупреждён, внешние сервисы заменены заглушками. Разберём, какие цифры смотреть, какими программами их получить и как по ним выбрать тариф.
Сайт, который быстро открывается у разработчика, может перестать отвечать, когда одновременно придут сто человек: закончатся процессы PHP, соединения с базой или память. Узнать об этом в день рекламной кампании дороже, чем за неделю до неё. Нагрузочный тест воспроизводит поток посетителей на вашем сервере и показывает, где предел и сколько до него осталось.
Что измерять
Результат теста — не одна цифра, а связка показателей, которые смотрят вместе:
- RPS (запросов в секунду) — сколько запросов сервер обрабатывает. Сам по себе RPS мало говорит: сервер может отвечать на тысячу запросов в секунду, но каждый ответ будет идти пять секунд.
- Время ответа по перцентилям — p95 означает, что 95% запросов уложились в это время, p99 — 99%. Среднее значение прячет медленные ответы: если 90 запросов прошли за 100 мс, а 10 — за 3 секунды, среднее около 400 мс выглядит прилично, хотя каждый десятый посетитель ждёт три секунды.
- Доля ошибок — ответы 5xx, обрывы соединения и таймауты. Ошибки под нагрузкой обычно появляются раньше, чем заметно растёт время ответа.
- Ресурсы сервера — загрузка процессора, свободная память и swap, ожидание диска (iowait), число соединений с базой. Эти данные снимают на самом сервере во время теста, иначе непонятно, во что упёрся сайт.
Цель формулируют заранее и в этих же единицах: например, «при 50 запросах в секунду p95 главной и каталога меньше 500 мс, ошибок меньше 1%». Без цели тест превращается в набор графиков, по которым ничего не решить.
Какие бывают тесты
- Дымовой — несколько виртуальных пользователей в течение минуты. Проверяет, что сценарий написан правильно, и даёт базовое время ответа без нагрузки.
- Нагрузочный — ожидаемый пиковый поток в течение 15–30 минут. Отвечает на вопрос, справляется ли сервер с плановой нагрузкой.
- Стресс-тест — нагрузку поднимают ступенями, пока не вырастут ошибки или время ответа. Показывает предел и то, как сайт ведёт себя за ним: отдаёт ошибку быстро или зависает.
- Длительный — умеренная нагрузка несколько часов. Находит утечки памяти, переполнение журналов и диска, накопление соединений.
Сценарий должен быть похож на настоящих посетителей: смесь страниц (главная, каталог, карточка, поиск), паузы между действиями, часть пользователей с авторизацией или корзиной. Тест, который тысячу раз в секунду запрашивает одну закэшированную страницу, измерит кэш, а не сайт.
Инструменты
Все четыре программы ниже бесплатны и запускаются из командной строки. Для сценариев с несколькими страницами подходят первые две, для быстрой проверки одного адреса — последние.
- k6 — сценарии пишутся на JavaScript, результат выводится сразу с перцентилями. В сценарии задают пороги: по документации k6 условие
http_req_failed: ['rate<0.01']иhttp_req_duration: ['p(95)<200']проверяется в конце теста, и при нарушении k6 завершается с ненулевым кодом. Поэтому k6 удобно встраивать в CI: сборка, после которой сайт стал медленнее, не пройдёт. - Apache JMeter — сценарии собираются в графическом интерфейсе: формы, авторизация, разбор ответов, данные из CSV. Сам тест рекомендуется запускать в режиме командной строки —
jmeter -n -t test.jmx -l test.jtl: графический режим тратит ресурсы генератора и искажает результат. - wrk — многопоточный генератор, который с одной машины создаёт большую нагрузку на один адрес. Пример:
wrk -t4 -c100 -d60s --latency https://example.com/— 4 потока, 100 соединений, минута, с распределением задержек. Сложные сценарии пишутся на Lua. - ab (ApacheBench) — самый простой вариант, часто уже установлен вместе с Apache. В документации прямо сказано, что ab реализует HTTP/1.x не полностью и при высокой нагрузке может измерять собственную скорость, а не сервера. Keep-alive по умолчанию выключен, его включают ключом
-k. Годится для быстрой проверки, но не для решения о тарифе.
Как тестировать, никому не мешая
Нагрузочный тест создаёт тот же поток запросов, что и наплыв посетителей, поэтому проводить его можно только на сервере, которым вы управляете, и с учётом правил площадки, где он стоит.
- Только свой сервер и свой домен. Нагрузка на чужие сайты и API без письменного согласия владельца недопустима, даже «на минуту». Если сайт обращается к платёжному шлюзу, службе доставки или внешнему API, на время теста их заменяют заглушками или тестовыми средами этих сервисов.
- Предупредите хостера. Защита от DDoS-атак у провайдера может принять тест за атаку и заблокировать адрес генератора, а правила некоторых хостеров требуют согласовывать такие проверки. Например, политика AWS разрешает стресс-тесты собственных подготовленных сервисов, но запрещает имитацию DDoS-атак. Короткое письмо в поддержку с датой, временем, адресами и ожидаемым объёмом снимает вопрос. Как устроена защита у хостеров, рассказано в статье Защита от DDoS у хостеров.
- Не на виртуальном хостинге. На общем сервере тест замедлит соседей, а результат будет зависеть от них. Тестируют на VPS или выделенном сервере, где ресурсы закреплены за вами.
- Генератор — на отдельной машине. Если запустить его на том же сервере, он отберёт процессор у сайта. Для генератора удобен VPS с почасовой оплатой: его создают на время теста и удаляют. По каталогу accsly.io на ноябрь 2026 года почасовая оплата прямо указана у 173 из 2 247 хостеров VPS, тарифы собраны на странице VPS с почасовой оплатой.
- Помните о трафике. Час теста может прокачать сотни гигабайт. Если в тарифе трафик лимитирован или канал делится с соседями, превышение оплачивается или скорость снижается — подробнее в статье Канал и трафик сервера.
- CDN и защита перед сайтом. Если домен подключён к CDN, тест через него проверит CDN и может упереться в его лимиты. Сервер-источник тестируют напрямую по его адресу, а нагрузку через CDN согласуют с провайдером CDN.
Как читать результат и выбирать тариф
При ступенчатом росте нагрузки RPS сначала растёт вместе с ней, а время ответа почти не меняется. Затем наступает точка насыщения: RPS перестаёт расти, p95 резко увеличивается, появляются ошибки. Рабочая нагрузка должна оставаться заметно ниже этой точки — запас нужен на всплески, фоновые задачи и рост аудитории. Удобный ориентир — чтобы ожидаемый пик занимал не больше половины найденного предела.
Дальше смотрят, во что упёрся сервер в точке насыщения:
- процессор загружен на 100% — нужны ещё ядра или более высокая частота, если узкое место в одном потоке; тарифы с частотой от 4 ГГц собраны на странице VPS с высокой частотой процессора;
- память закончилась и сервер ушёл в swap — нужна память или меньше процессов PHP-FPM и воркеров; ориентиры по объёму — в статье Сколько памяти и ядер нужно сайту;
- высокий iowait — диск не успевает, обычно из-за базы данных; помогает NVMe и индексы, сравнение — в статье NVMe или SSD;
- ресурсы свободны, а ошибки есть — упёрлись в настройки: лимит соединений базы, число воркеров веб-сервера, открытых файлов.
Перед покупкой тест стоит повторить на том тарифе, который вы собираетесь брать: процессоры и диски у хостеров различаются сильнее, чем цифры в описании. Удобнее всего — на почасовой оплате или в пробный период, как описано в статье Как проверить пинг и скорость VPS до оплаты. После запуска те же показатели — время ответа, ошибки, загрузку ресурсов — переводят в мониторинг, чтобы рост нагрузки был виден до того, как сайт начнёт отвечать ошибками.