Нагрузочное тестирование сайта: когда нужно и как проходит

12 июля 2026 · Команда SaitHub · Тестирование и QA

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

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

Когда нагрузочное тестирование обязательно

Есть четыре ситуации, когда пропускать тест — значит осознанно играть в рулетку с трафиком и репутацией.

• Перед запуском платной рекламы. Кампания в Яндекс.Директе, посевы в Telegram-каналах, таргет — всё это приводит трафик волнами: за первые часы после старта посещаемость может вырасти в 10–20 раз. Если сайт не готов, вы заплатите за клики, которые упрутся в «сервер не отвечает». Деньги списаны, заявок нет.
• Перед сезоном или акцией. «Чёрная пятница», Новый год, старт продаж, ограниченная по времени скидка. Пиковая нагрузка в такие дни превышает обычную в 5–15 раз, а стоимость каждого часа простоя — максимальна за весь год: клиенты пришли покупать прямо сейчас и второго шанса не дадут.
• После переезда на новый хостинг или сервер. Новая площадка может выглядеть быстрее на пяти посетителях и при этом держать вдвое меньшую пиковую нагрузку — из-за других лимитов PHP-воркеров, настроек базы данных или более медленных дисков. Пока не прогнали тест, реальный запас прочности после переезда — неизвестная величина.
• Перед выходом в СМИ или крупную публикацию. Упоминание в популярном издании, сюжет на ТВ, пост у миллионника — это резкий одномоментный наплыв посетителей, который невозможно «размазать» по времени. Классический сценарий: о компании написали, тысячи людей кликнули по ссылке, сайт лёг, и вместо потока клиентов бизнес получил поток скриншотов с ошибкой.

Виды нагрузочных тестов: не всё сводится к «нагнать побольше»

Под словами «нагрузочное тестирование» скрывается пять разных типов проверок. Они отвечают на разные вопросы, и грамотный тест-план почти всегда включает несколько из них.

Smoke-тест — короткий прогон с минимальной нагрузкой, буквально 5–10 виртуальных пользователей на пару минут. Его задача — убедиться, что сценарии написаны верно, сайт отвечает, авторизация и корзина работают. По сути, это проверка самого теста перед «боевыми» прогонами.

Load-тест — основная проверка на ожидаемой нагрузке. Мы берём реалистичную цифру (например, прогнозируемый пик рекламной кампании) и смотрим, как сайт держит её в течение 20–40 минут: не растёт ли время ответа, не появляются ли ошибки. Ответ на вопрос «выдержим ли мы то, что планируем».

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

Soak-тест (endurance) — умеренная нагрузка на длинной дистанции, от нескольких часов до суток. Он ловит проблемы, которые не видны на коротких прогонах: утечки памяти, переполнение логов и временных таблиц, деградацию соединений с базой. Сайт, который бодро держит час, может «протечь» и упасть на шестом часу распродажи.

Spike-тест — резкий скачок нагрузки: с 50 пользователей до 1000 за секунды и обратно. Именно так выглядит трафик после email-рассылки, пуш-уведомления или выхода сюжета в СМИ. Тест показывает, переживает ли система мгновенный наплыв и как быстро восстанавливается после него.

Как проходит тестирование

1. Профиль нагрузки. Изучаем аналитику: сколько людей, на какие страницы, какие действия, в какой пропорции. Тест «в лоб на главную» бесполезен — главная почти всегда закеширована и держит тысячи запросов, а ломаются обычно корзина, поиск и оформление заказа, где кеш не работает. Если исторических данных нет, строим профиль от медиаплана рекламной кампании.
2. Сценарии. Виртуальные пользователи ходят по сайту как реальные: каталог → карточка → корзина → оформление. С паузами «на подумать», разными товарами и долей тех, кто пользуется поиском или бросает корзину. Чем ближе сценарий к реальному поведению, тем достовернее результат.
3. Ступенчатая нагрузка. Поднимаем число пользователей ступенями: 100 → 500 → 1000 → до отказа. На каждой ступени фиксируем время ответа, долю ошибок и состояние сервера. Отмечаем две границы: где время ответа превышает 2–3 секунды (комфорт кончился) и где начинаются ошибки (система отказывает).
4. Отчёт. Не пачка графиков, а выводы на языке бизнеса: предел системы в пользователях и заказах в минуту, узкое место (база, PHP-воркеры, память, внешние API) и приоритизированные рекомендации — что оптимизировать в коде, а что просто масштабировать ресурсами и за какие деньги.

Ключевые метрики: что означают цифры в отчёте

Отчёт о нагрузочном тесте оперирует несколькими показателями. Разберём их простыми словами — чтобы результаты можно было читать без переводчика с технического.

• RPS (запросов в секунду) — «пропускная способность» сайта, сколько обращений он обрабатывает за секунду. Один посетитель генерирует несколько запросов, поэтому RPS всегда выше числа людей. Это главная цифра ёмкости: её сравнивают с прогнозом трафика.
• Время ответа p95 и p99 — не «среднее», а честная граница: p95 — время, в которое укладываются 95% запросов, p99 — 99%. Среднее умеет врать: при среднем 0,8 секунды каждый двадцатый посетитель может ждать по шесть. Для бизнеса важно именно p95/p99 — это опыт худших, но всё ещё массовых случаев.
• Error rate (доля ошибок) — процент запросов, завершившихся ошибкой 5xx или таймаутом. Норма под нагрузкой — доли процента. Уже 1–2% ошибок на оформлении заказа означает, что каждый пятидесятый покупатель не смог заплатить.
• Деградация базы данных — рост времени выполнения запросов к БД под нагрузкой. База — самое частое узкое место: запрос, который на тестовых данных выполнялся 20 мс, при 500 одновременных пользователях без нужного индекса растягивается до секунд и тянет за собой весь сайт.
• «Полка» CPU и RAM — момент, когда процессор или память сервера упираются в 100% и график превращается в горизонтальную линию. После полки система не обрабатывает больше, сколько бы пользователей ни пришло: запросы копятся в очереди, время ответа растёт лавинообразно. Расстояние от рабочей нагрузки до полки и есть ваш запас прочности.

Что именно проверяем: сценарии и критерии успеха

Для типового интернет-магазина или сайта услуг тест-план выглядит примерно так:

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

Инструменты в 2026 году: чем нагружаем

Инструментов много, но на практике выбор сводится к четырём проверенным.

• k6 — современный стандарт де-факто. Сценарии пишутся кодом на JavaScript, тесты легко встраиваются в CI/CD и версионируются вместе с проектом. Экономно расходует ресурсы: тысячи виртуальных пользователей с одной машины. Наш выбор по умолчанию для большинства задач.
• Apache JMeter — ветеран с графическим интерфейсом и огромной экосистемой плагинов. Умеет почти всё, включая экзотические протоколы, но тяжелее в поддержке и прожорливее по памяти. Берём, когда нужны специфические протоколы или у заказчика уже есть наработки на нём.
• Yandex.Tank — открытый инструмент Яндекса, заточенный под высокие нагрузки и подробную статистику по перцентилям. Удобен связкой с сервисом Overload для хранения и сравнения результатов. Хороший вариант, когда нужно «продавить» действительно большой RPS с минимальными усилиями.
• Locust — сценарии на Python, легко описывать сложное поведение пользователей и распределять нагрузку на несколько машин. Выбираем, когда логика сценариев нетривиальная, а команда заказчика пишет на Python и будет поддерживать тесты сама.

Важно понимать: инструмент — 20% результата. Остальные 80% — правильный профиль нагрузки, реалистичные сценарии и грамотная интерпретация цифр.

Мини-кейс: с 300 до 2000+ пользователей без смены сервера

Интернет-магазин стройматериалов запустил кампанию в Яндекс.Директе с бюджетом около 300 000 ₽ в месяц. В первый же пиковый вечер сайт начал отдавать ошибки при ~300 одновременных посетителях: страницы каталога открывались по 12–15 секунд, треть заявок терялась.

Стресс-тест на копии продакшена подтвердил цифру и показал узкие места: тяжёлые SQL-запросы фильтра каталога без индексов, полное отсутствие кеширования страниц и отдача изображений (60% трафика) с того же сервера, что и приложение. Что сделали за две недели:

• добавили индексы и переписали три самых тяжёлых запроса — время ответа базы под нагрузкой упало с 1,8 с до 40 мс;
• включили кеширование каталога и карточек — 85% запросов перестали доходить до PHP и базы;
• вынесли статику и изображения на CDN — сервер разгрузился по каналу и CPU.

Контрольный прогон после оптимизации: сайт стабильно держит 2000+ одновременных пользователей с p95 около 0,9 секунды и нулевой долей ошибок — рост предела прочности в 6–7 раз на том же сервере. Стоимость работ (тест, оптимизация, контрольный прогон) — 120 000 ₽, то есть меньше половины месячного рекламного бюджета. Эффект: конверсия из рекламы выросла в 1,8 раза только за счёт того, что сайт перестал «тормозить и падать» в пиковые часы, а запланированный апгрейд сервера не понадобился.

Что делать с результатами теста

Тест ради теста бессмысленен — ценность в действиях после него. По итогам отчёта обычно выстраивается короткий план: сначала дешёвые точечные исправления (индексы, кеш, лимиты воркеров), затем — при необходимости — архитектурные изменения и масштабирование. Часто нагрузочный тест заказывают вместе с аудитом сайта: аудит находит проблемы «в ширину», тест — измеряет их «в глубину» под нагрузкой.

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

Частые вопросы

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

Тест типового сайта или магазина — от 40 000 ₽: профиль нагрузки, сценарии, прогоны, отчёт с разбором узких мест. Тест плюс исправления «под ключ» с контрольным прогоном — обычно 80 000–150 000 ₽ в зависимости от масштаба проблем. Для сравнения: один сорванный день распродажи у среднего магазина стоит дороже.

Можно ли тестировать боевой сайт?

Осторожно — да. Прогоны ставят на часы минимального трафика (обычно ночь), нагрузку поднимают плавно и останавливают при первых признаках деградации, тестовые заказы помечают, чтобы не смешивать с реальными. Но stress-тест «до отказа» на проде мы не делаем — для него разворачивается копия окружения.

Как часто повторять тесты?

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

У нас мало трафика — нам это вообще нужно?

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

Что мы получим на руки?

Отчёт с цифрами предела (пользователи, RPS, заказы в минуту), графики времени ответа и ошибок по ступеням нагрузки, список узких мест с приоритетами и план исправлений с оценкой стоимости. Сценарии тестов остаются у вас — повторный прогон после доработок стоит заметно дешевле первого.

Сколько это стоит и что потом

Нагрузочный тест типового сайта или магазина — от 40 000 ₽ в составе QA-работ: сценарии, прогоны, отчёт с разбором. По итогам обычно хватает точечных исправлений — индексы в базе, кеширование, лимиты воркеров — чтобы поднять предел в 2–5 раз без покупки железа. Если же узкое место архитектурное, вы узнаете об этом заранее и спланируете изменения без аврала.