«Сайт лёг». Эта фраза вызывает холодный пот у любого владельца бизнеса. Вы запустили рекламу, получили ожидаемый трафик... и вместо заявок — белый экран и ошибка 503 или 500. Клиенты уходят к конкурентам, бюджет слит, репутация подмочена.
В этой статье — разбор типичных технических причин, по которым сайт падает при росте нагрузки (от 100 до 10 000 посетителей). И главное — что сделать, чтобы этого не произошло. Большинство проблем решается настройкой, а не переписыванием сайта с нуля.
Как выглядит «падение сайта» под нагрузкой
- Страницы грузятся очень медленно (10-30 секунд или вечность). Пользователь закрывает сайт.
- Появляются ошибки 503 Service Unavailable. Сервер не справляется с количеством одновременных запросов.
- Ошибки 500 Internal Server Error. Сломалась логика приложения (закончилась память, превышено время выполнения, упал база данных).
- Бесконечная загрузка (белый экран). PHP-процесс завис в ожидании чего-то (БД, внешнего API).
- База данных «логинится» (Too many connections). MySQL не справляется с числом параллельных запросов.
- Некорректное отображение (ломается вёрстка, не грузятся css). CDN или сервер раздачи статики не выдержал.
Часто сайт не падает «весь», а «тормозит» какие-то страницы и функции. Но для клиента разницы нет — он уходит.
8 типичных «узких горлышек», которые убивают сайт
1. Слабый хостинг (shared hosting)
Обычный дешёвый хостинг за 300-1000 ₽/месяц делит ресурсы одного сервера между 500-1000 сайтами. Ваш сосед отъел процессор, пришёл трафик — и всё. Ресурсов просто нет.
Предотвращение: Переход на VPS/VDS с гарантированными ресурсами (от 2000-5000 ₽/мес). Для серьёзного буфера — облачные серверы (Yandex Cloud, Selectel), которые можно быстро масштабировать.
2. Неоптимизированная база данных
Десятки (или сотни) запросов к MySQL на каждую страницу, нет индексов, огромные таблицы. При 10 посетителях база ещё успевает. При 500 — падает.
Предотвращение: Включить медленный лог запросов (slow query log) и найти самые тормозные запросы. Добавить индексы. Установить плагин кеширования запросов (например, Redis или Memcached).
3. Отсутствие кеширования страниц
Каждый посетитель заставляет сервер полностью генерировать страницу: инициализировать PHP, выполнить SQL-запросы, собрать HTML. Это в 10-100 раз «тяжелее», чем просто отдать готовый статический файл.
Предотвращение: Включить кеширование страниц (Page Cache). Для WordPress плагины WP Rocket, W3 Total Cache, LiteSpeed. Страница будет генерироваться один раз, а потом отдаваться статикой тысячам пользователей.
4. PHP-процессы «заканчиваются»
У вас настроено max 30 одновременных PHP-процессов (настройка PHP-FPM). При 40 параллельных пользователях — лишние 10 стоят в очереди (сайт висит) или получают ошибку.
Предотвращение: Увеличить количество процессов PHP-FPM (max_children, start_servers). Следить за потреблением памяти (php-fpm status page).
5. Длинные операции, блокирующие ответ пользователю
Отправка письма, парсинг PDF, генерация отчёта, запрос к медленному внешнему API. Пользователь ждёт 30 секунд, серверный таймаут — ошибка 504.
Предотвращение: Выносить длительные задачи в очередь (RabbitMQ, Redis). Пользователь получает ответ мгновенно («принято в обработку»), а задача выполняется фоном.
6. «Тяжёлые» изображения и неоптимизированный фронтенд
Картинки по 10 МБ, десятки файлов CSS/JS, не подключён сжатие gzip/brotli. Это не столько убивает сервер, сколько вынуждает пользователя уходить от долгой загрузки.
Предотвращение: Сжатие изображений (ShortPixel, Imagify), конвертация в WebP, минификация CSS/JS, подключение CDN (Cloudflare). Включение сжатия gzip на сервере.
7. Проблемы с внешними API (сторонние сервисы)
На сайте виджет погоды, отзывы с Яндекс.Карт, трекер доставки. Внешний сервис тормозит или не отвечает. Ваш сайт ждёт, пока он ответит. В итоге виснут все страницы, где есть этот виджет.
Предотвращение: Все вызовы внешних API делать асинхронными (через JavaScript, отдельный поток). Чтобы задержка внешнего сервиса не блокировала показ основного содержимого.
8. Утечки памяти (memory leak)
Код или плагин со временем потребляет всё больше памяти. При створации каждого нового посетителя память не освобождается. В конце концов память кончается, сервер перезагружается.
Предотвращение: Мониторинг памяти (New Relic, встроенный мониторинг хостинга). Тестирование с имитацией длительной работы.
Как предотвратить коллапс до того, как он случится
1. Нагрузочное тестирование (Stress test). Это самое главное, что вы можете сделать. Запустите Яндекс.Танк, JMeter или Loader.io. Узнайте:
- Сколько одновременных пользователей выдерживает сайт.
- При каком количестве запросов время ответа превышает 2 секунды.
- Когда начинаются ошибки (4xx, 5xx).
2. Мониторинг реального времени. Настройте Zabbix, Grafana или встроенные мониторинги хостинга. Вы должны видеть:
- CPU, память, нагрузку на диск (iowait).
- Количество активных PHP-процессов.
- Количество подключений к MySQL, медленные запросы.
- HTTP-коды ошибок (4xx, 5xx) в реальном времени.
3. План аварийного восстановления (Runbook). Напишите простую инструкцию на 2 страницы:
- Кого звонить (администратор, разработчик).
- Какие кнопки нажать в панели управления хостингом, чтобы увеличить power сервера (скейлинг).
- Как отключить «тяжёлую» функцию (поиск, виджет, рейтинг) временно.
- Как включить «офлайн-режим» и показать статическую заглушку «Мы временно перегружены, оставьте телефон».
4. Лавинная защита (дросселирование). Настроить nginx/Cloudflare на ограничение количества запросов с одного IP в секунду. При превышении — отдавать 429 Too Many Requests, а не крашить сервер.
5. Регулярная оптимизация (а не «перед сезоном»). Дефрагментация таблиц, обновление статистики MySQL, ревью плагинов.
Что делать, если сайт уже падает (аварийные действия)
- Увеличить ресурсы сервера в панели управления: Сменить тариф на более мощный (больше CPU/RAM). Это делается за 1-2 минуты.
- Временно выключить «тяжёлые» плагины (поиск, боковики, рекомендуемые товары). Часто это помогает резко снизить нагрузку.
- Включить Surmaintenance Mode (заглушку «сайт на обслуживании»), чтобы пользователь видел не ошибку, а приятную форму сбора контактов.
- Отключить логирование запросов и дебаг-режим.
- Увеличить лимиты PHP (memory_limit, max_execution_time, max_input_vars).
- Если база данных падает (Too many connections) — временно добавить параметр max_connections в MySQL (аккуратно, может не хватить RAM).
- Включить кеширование на уровне веб-сервера (nginx cache) или Cloudflare «Even под нагрузкой».
⚡ Стресс-тест и аудит выживаемости вашего сервера
Проведём нагрузочное тестирование вашего сайта: эмулируем 200, 500, 1000 и 5000 пользователей. Вы получите отчёт: при каком RPS начинаются ошибки, какие запросы тормозят, что менять в первую очередь. Окупится первым же часом пик без простоя.
👉 Оставьте заявку на сайте edgesection.ru или напишите в Telegram. Укажите «Тест нагрузки».
Настройка и оптимизация highload-проектов.
Резюме: главное о стабильности сайта
- Сайт ломается при нагрузке из-за узких горлышек: слабый хостинг, отсутствие кеширования, медленные запросы к БД, нехватка PHP-процессов.
- Нагрузочное тестирование — это единственный способ узнать реальный «потолок» до того, как это увидят клиенты.
- Быстрые победы: кеш страниц, CDN, мощный VPS, оптимизация картинок.
- Мониторинг в реальном времени поможет среагировать за 5 минут, а не через час после отвала сайта.
- Не ждите сезона или вирусной рекламы. Подготовьте сайт заранее. Дешевле и спокойнее.
