Распродажа, рассылка по большой базе, сюжет в СМИ или удачная публикация создают нагрузку, к которой обычный хостинг не готов. Сайт при этом редко падает совсем: сначала он просто отвечает медленно, потом отдаёт ошибки части посетителей, и только затем перестаёт открываться. Разберём, что сделать заранее и что делать в день события.
Что именно ломается под нагрузкой
Опыт разборов после сбоев показывает один и тот же порядок отказов. Первой обычно ложится база данных: тяжёлые запросы без индексов, подсчёт общего количества товаров на каждой странице каталога, выборки по фильтрам без ограничений. Второй кандидат — генерация страниц без кэша, когда каждый посетитель заставляет сервер собирать одну и ту же страницу заново.
Дальше срабатывает эффект очереди: медленные запросы удерживают соединения, свободные процессы заканчиваются, и посетители получают ошибку даже на тех страницах, которые сами по себе лёгкие. Более мощный сервер эти проблемы отодвигает, но не решает: при вдвое большем потоке всё повторится.
Замер: с чего начинается подготовка
Готовиться вслепую бессмысленно, поэтому первым шагом мы измеряем текущее состояние.
- Проводим нагрузочный тест на копии сайта и находим границу, после которой время ответа резко растёт.
- Смотрим журнал медленных запросов к базе и выписываем самые тяжёлые.
- Находим самые тяжёлые страницы: обычно это каталог с фильтрами, поиск и корзина.
- Считаем, сколько внешних запросов делает страница: виджеты, счётчики, шрифты, карты.
- Оцениваем запас по ресурсам у текущего тарифа хостинга и узнаём, как быстро его можно расширить.
Результат замера — не общая оценка «сайт быстрый или медленный», а список конкретных мест, которые упрутся первыми. По нему и составляется план работ.
Что даёт наибольший эффект
| Мера | Эффект | Сложность |
|---|---|---|
| Кэш готовых страниц | Очень высокий | Средняя |
| Оптимизация запросов к базе и индексы | Высокий | Средняя |
| Раздача картинок и статики через отдельный сервис | Высокий | Низкая |
| Сжатие изображений и отложенная загрузка | Средний | Низкая |
| Отключение лишних виджетов на время пика | Средний | Низкая |
| Кэш результатов запросов в памяти | Средний | Средняя |
| Увеличение ресурсов сервера | Средний | Низкая, но платно |
| Вынос тяжёлых операций в фоновые задачи | Средний | Высокая |
Порядок в таблице отражает наш обычный приоритет работ. Увеличение ресурсов стоит внизу не потому, что оно бесполезно, а потому, что без первых пунктов оно даёт кратный, а не качественный выигрыш и заканчивается тем же отказом при большем потоке.
Кэш: три уровня
Слово «кэш» обозначает несколько разных механизмов, и путать их не стоит.
- Кэш страниц. Готовый HTML отдаётся без обращения к коду и базе. Самый сильный приём для каталога и статических разделов. Требует аккуратной настройки исключений: корзина, личный кабинет и оформление заказа кэшироваться не должны.
- Кэш данных. Результаты частых запросов хранятся в памяти: меню, дерево категорий, счётчики, блоки на главной. Помогает там, где страницу целиком закэшировать нельзя.
- Кэш браузера и статики. Картинки, стили и шрифты отдаются с длительным сроком хранения и версией в адресе файла. Снимает часть повторных запросов от вернувшихся посетителей.
Отдельно проверяем, что кэш действительно работает: наличие модуля не означает, что страницы попадают в него. Мы смотрим заголовки ответа и долю попаданий, а не только настройки в панели.
База данных
Работы по базе редко выглядят эффектно, но именно они чаще всего снимают отказ.
- Разбираем журнал медленных запросов и добавляем недостающие индексы.
- Убираем подсчёт общего количества записей там, где он не нужен для отображения.
- Ограничиваем выборки по фильтрам и запрещаем комбинации, которые никто не использует.
- Выносим тяжёлые отчёты за пределы рабочего времени или на отдельную копию базы.
- Проверяем, что поиск по сайту не делает полный перебор таблицы товаров.
Картинки и внешние скрипты
Изображения обычно составляют большую часть веса страницы, а внешние скрипты — большую часть времени до готовности. Перед пиковым событием мы приводим в порядок и то, и другое: сжимаем изображения, отдаём их в современном формате, включаем отложенную загрузку для всего, что ниже первого экрана, и пересматриваем список подключённых виджетов. Часть из них ставилась когда-то под задачу, которой давно нет, и продолжает грузиться на каждой странице.
В день события
- Никаких выкладок кода и правок шаблона: любое изменение в этот день умножает риск.
- Мониторинг доступности и времени ответа с уведомлением на телефон.
- Дежурный, который может увеличить ресурсы или отключить тяжёлый блок без согласований.
- Заранее подготовленная страница-заглушка на случай аварии, с контактами и сроком.
- Понятный порядок действий: что отключаем первым, вторым и третьим, если нагрузка растёт.
- Договорённость с хостингом о том, кто и как быстро реагирует на обращение.
Полезно заранее решить, чем можно пожертвовать. Отключить рекомендации, отзывы, тяжёлый поиск по фильтрам или анимации проще, чем потерять оформление заказа целиком. Список таких блоков стоит составить до события, а не искать их в момент отказа.
После события
Разбор занимает несколько часов и даёт готовый список задач к следующему сезону. Мы смотрим, какие страницы отвечали медленнее всего, были ли ошибки и в какие минуты, сколько запросов пришлось на пик, как вела себя база и где заканчивались процессы. Отдельно сверяем, дошли ли заявки и заказы: иногда сайт держался, а письма из форм терялись.
Эти данные ценнее любых общих рекомендаций: они показывают ваши узкие места, а не средние по отрасли.
Подготовим сервер к пику
Мы проводим нагрузочный тест, настраиваем кэширование, разбираем медленные запросы и готовим план действий на день события. Работы планируются заранее, чтобы правки успели отстояться до пика. Если распродажа или рассылка уже в календаре, возьмём на себя настройку и оптимизацию сервера и подготовим сайт к нагрузке.
