Реклама привела покупателей, каталог ещё открывается, а корзина уже зависает. Затем появляются ошибки 502, и часть клиентов не может оформить заказ. Для интернет-магазина это уже отказ, даже если главная страница продолжает работать. В пиковый день такой отказ обходится особенно дорого — во что на самом деле обходится простой, мы разбирали отдельно.

Когда магазин на 1С-Битрикс тормозит или падает под нагрузкой, причину ищут по всей цепочке обработки запроса: веб-сервер, PHP, база данных, кеш и интеграции. Ниже — семь причин, с которых стоит начать, и восьмая ситуация, когда дело уже не в оптимизации, а в архитектуре. Порядок не отражает частоту: конкретное узкое место показывают метрики и журналы.

Сначала определите, что именно перестало работать

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

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

Симптом → вероятная причина → что проверить

1. Кеш не снимает повторную работу

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

Сравните первый и повторный запросы к одной странице: время выполнения, количество SQL-запросов, создание и чтение кеша. Затем выясните, какие события его сбрасывают. Самый опасный момент — очистка кеша в пик: все посетители одновременно заставляют приложение заново собирать одни и те же данные. Если замедление совпадает с обновлением каталога, начните расследование именно с этой связи.

Композитный режим не заменяет оптимизацию корзины. Он быстро отдаёт сохранённую часть страницы, а динамические области получают актуальные данные отдельным запросом. Быстрый первый экран ещё не означает, что покупатель сможет завершить заказ. После любых изменений кеширования проверьте цены, остатки и то, что разные пользователи видят свои данные.

2. Каталог, фильтры и поиск перегружают базу данных

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

Начните с проблемных страниц. Монитор производительности Битрикса показывает SQL-запросы страницы вместе со стеком вызова, и это помогает связать запрос с конкретным кодом. На стороне MySQL журнал медленных запросов показывает операции, превысившие заданный порог. Для полной картины добавьте частоту выполнения, план запроса и ожидания блокировок.

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

Загляните и в модуль «Веб-аналитика»: он записывает в базу данные о каждом хите. Если статистику уже собирают внешние системы, модуль часто можно отключить и избавить базу от постоянной записи.

Оценивайте не количество SQL-запросов, а их стоимость и повторяемость. Разработчик решает, где сократить выборку, убрать дублирование или добавить индекс, и проверяет результат на том же сценарии нагрузки. Если собственной команды разработки нет, эту работу берёт на себя техподдержка проектов на 1С-Битрикс.

3. Все обработчики PHP заняты

В конфигурации с PHP-FPM число одновременно обслуживаемых запросов ограничено параметром pm.max_children. Когда все обработчики заняты, новые запросы встают в очередь. Процессор при этом может быть загружен умеренно: часть процессов просто ждёт ответа от базы данных или внешнего API.

Смотрите на очередь listen queue, число активных процессов, прирост счётчика max children reached за время инцидента и журнал медленных PHP-запросов. Учтите, что счётчик копится с момента запуска пула, поэтому важен именно его рост во время сбоя, а не само ненулевое значение.

Число процессов увеличивают с оглядкой на память и нагрузку на базу, иначе одно ограничение сменится другим. Сначала выясните, чем заняты обработчики и почему запросы выполняются долго, — часто ответ находится в разделах 2 и 6.

4. Обмен с 1С и фоновые задачи совпадают с пиком

Импорт товаров, обработка изображений и резервное копирование тоже потребляют ресурсы. Если они идут одновременно с наплывом покупателей, проверьте, не конкурируют ли они с пользовательскими запросами за диск, процессор и базу данных.

Агенты Битрикса — периодически выполняемые PHP-функции. По умолчанию они запускаются на хитах посетителей, и тяжёлая задача может увеличить время ответа конкретному покупателю. Перевод агентов на cron (в документации это включается константой BX_CRONTAB_SUPPORT) отделяет их запуск от посещений, но не делает сами задачи легче.

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

5. Серверу действительно не хватает ресурсов

У любого, даже хорошо оптимизированного магазина есть предел мощности. Проверьте загрузку CPU, доступную память, использование swap, задержки дисковых операций, свободное место и лимиты тарифа хостинга. Если операционная система завершила процесс из-за нехватки памяти, это видно в системном журнале.

Число посетителей за сутки не говорит, выдержит ли сервер распродажу. Важны одновременные запросы и то, что делают покупатели: просмотр закешированной страницы и пересчёт корзины создают совершенно разную нагрузку.

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

6. Оформление заказа ждёт внешний сервис

Типичная ситуация: при оформлении заказа магазин синхронно обращается к службе доставки, платёжному сервису или CRM, а тот отвечает медленно. Пока приложение ждёт, запрос покупателя висит. При большом числе таких обращений ожидание занимает все обработчики PHP — и тормозить начинает весь сайт, а не только checkout.

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

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

7. Боты создают нагрузку на дорогие страницы

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

Ограничение частоты запросов сдерживает отдельные потоки, но правила стоит проверять на реальных сценариях: за одним IP могут стоять десятки покупателей из одного офиса, а под ограничение не должны попасть оформление заказа и нужные интеграции. Часть нагрузки можно снять ещё до сервера — статику и фильтрацию трафика берёт на себя CDN. От атаки, которая уже забивает сетевой канал, настройки веб-сервера не спасут: её отражают на уровне сети.

8. Когда одного сервера уже мало

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

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

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

Что делать во время сбоя и перед следующей акцией

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

1. Определите масштаб: недоступен весь магазин или отдельный этап покупки.
2. Зафиксируйте время, ошибки, очередь PHP, состояние базы и ресурсы сервера. Если нужен срочный перезапуск, сохраните доступные сведения до него.
3. Проверьте, что изменилось перед сбоем: релиз, обмен с 1С, фоновые задачи, объём или характер трафика.
4. Снизьте подтверждённый источник нагрузки. Откат релиза, остановку задачи или ограничение трафика выбирайте так, чтобы не повредить заказы.
5. После восстановления пройдите покупку целиком, проверьте статусы оплат и отсутствие дублей. Открывшаяся главная страница — ещё не признак восстановления.

Чтобы не импровизировать в момент аварии, роли и порядок действий распределяют заранее — об этом в материале про роль инцидент-менеджера.

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

Сравнивайте не только среднее время ответа, но и долю ошибок, очереди и p95 — время, в которое укладываются 95% запросов. Допустимые значения задавайте отдельно для каждого сценария. А чтобы при следующем сбое было что анализировать, метрики должны собираться постоянно: как связать наблюдение за системой с реакцией команды, рассказываем в статье про проактивный мониторинг 24/7.

FAQ

Почему сайт на Битриксе выдаёт ошибку 502 под нагрузкой?

Чаще всего веб-сервер не дождался ответа от PHP: все процессы PHP-FPM заняты, потому что ждут базу данных, внешний API или выполняют тяжёлый код. Сам код 502 не называет причину — её показывают журналы Nginx и PHP, очередь PHP-FPM и состояние базы за то же время.

Как подготовить Битрикс к распродаже?

Проверьте медленные SQL-запросы и фасетный индекс, стратегию кеширования и сценарии его сброса, расписание обмена с 1С и агентов, время ответа внешних сервисов. Затем проведите нагрузочный тест сценариев покупки с холодным и прогретым кешем.

Поможет ли просто увеличить сервер?

Если магазин действительно упирается в процессор, память или диск — да. Но дополнительные ресурсы не исправят неоптимальный SQL, медленный внешний API или компонент, который на каждом хите делает лишнюю работу.

Может ли обмен с 1С положить интернет-магазин?

Может, если массовое обновление каталога совпадает с пиком посещаемости: обмен активно пишет в базу и сбрасывает кеш, а покупатели в это время продолжают открывать каталог. Поэтому обмен анализируют вместе с нагрузкой на MySQL, PHP и кеш в тот же период.

Когда интернет-магазину на Битриксе нужен кластер?

Когда оптимизированное приложение регулярно достигает предела одного сервера или нужно убрать единую точку отказа. Решение принимают по результатам измерений и нагрузочного тестирования.

Если сбои повторяются

Повторяющиеся падения стоит разбирать вместе разработчику и специалисту по инфраструктуре: проблема часто находится на границе кода, сервера и интеграций. U-Team проводит аудит инфраструктуры, чтобы найти узкое место до следующего пика, и берёт на себя сопровождение IT-инфраструктуры. Объём работ для конкретного магазина определяют после диагностики. О том, как в целом выстроить эксплуатацию магазина, читайте в материале DevOps для интернет-магазина.