Рефакторинг OpenCart под нагрузкой: что ломается первым

Магазин на OpenCart 3.x может работать быстро на тестовой витрине и начать отдавать 502 под нагрузкой уже после добавления нескольких фильтров, интеграций и модификаторов. Первым обычно ломается не один конкретный модуль, а цепочка: PHP-FPM упирается в число процессов, запросы к MySQL занимают воркеры, а OCMOD и VQMod усложняют поиск места, где возникла задержка.

Что считать поломкой под нагрузкой

Для OpenCart проблема начинается раньше полного падения. Страница может формально открываться, но карточка товара отвечает 4–6 секунд, оформление заказа периодически получает 500, а панель администратора зависает из-за тех же ресурсов, которые заняла витрина.

Порядок отказа зависит от каталога, схемы кэширования, версии PHP, настроек PHP-FPM, базы данных и набора расширений. Поэтому утверждение «первым всегда ломается база» слишком грубое. У магазина с тяжёлым поиском это действительно может быть MySQL, а у магазина с большим числом внешних API — PHP-процессы, ожидающие ответа от стороннего сервиса.

Главный объект рефакторинга в перегруженном OpenCart — не отдельный модификатор, а время жизни одного веб-запроса.

Где возникает очередь

Запрос к витрине проходит через несколько слоёв: веб-сервер передаёт его PHP, OpenCart загружает конфигурацию и контроллер, модели обращаются к базе, модификации меняют исходное поведение, а затем система формирует HTML. Если один этап задержался, занятый PHP-воркер не может обслужить следующий запрос.

PHP-FPM-воркер — отдельный процесс или поток обработки PHP-запроса. Когда все доступные воркеры заняты, новые соединения ждут в очереди. Посетитель видит медленную загрузку или ошибку, хотя CPU сервера может быть далёк от 100 процентов.

На практике полезно разделять четыре времени:

• ожидание соединения с веб-сервером и PHP-FPM;
• выполнение PHP-кода OpenCart и модификаций;
• ожидание и выполнение SQL-запросов;
• ответы внешних сервисов: оплаты, доставки, CRM, складской системы.

Среднее время ответа скрывает проблему. Для нагрузки смотрите как минимум медиану и 95-й перцентиль: последняя метрика показывает, сколько ждут самые медленные 5 процентов запросов.

Что ломается первым

1. Внешний вызов внутри обычной страницы

Интеграция с остатками, ценами или доставкой часто вызывается прямо при открытии каталога или корзины. Пока сервис отвечает быстро, это незаметно. При задержке стороннего API каждый PHP-воркер простаивает, а новые запросы становятся в очередь.

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

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

2. Повторяющиеся SQL-запросы

Модификатор может добавить проверку в контроллер, модель или шаблон. Если проверка выполняет SQL внутри цикла товаров, количество запросов растёт вместе с размером выдачи. Это типичный случай N+1: сначала загружается список товаров, а затем для каждого товара отдельно читаются остатки, скидки или дополнительные поля.

Наличие индекса само по себе не исправляет такую схему. Индекс ускоряет отдельный запрос, но двадцать быстрых запросов всё равно создают лишние сетевые переходы, разбор SQL и блокировку соединения.

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

3. Запросы без подходящего индекса

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

Смотрите план выполнения конкретного запроса средствами вашей версии MySQL или MariaDB. Важно проверить не только наличие индекса, но и его фактическое использование, число прочитанных строк и сортировку. Добавлять индексы вслепую опасно: они ускоряют чтение, но увеличивают размер базы и стоимость операций записи.

4. Исчерпание PHP-FPM

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

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

5. Конфликт модификаций

OCMOD и VQMod меняют путь выполнения не одинаково. OCMOD формирует изменённые копии файлов в каталоге модификаций после обновления или очистки кэша. VQMod подменяет или оборачивает выполнение файлов во время запроса. Точная картина зависит от версии и установленных расширений.

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

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

Как измерять до рефакторинга

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

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

В отчёте нужны:

• медиана, 95-й и 99-й перцентили времени ответа;
• число запросов в секунду и доля ошибок 4xx и 5xx;
• время выполнения PHP и ожидания PHP-FPM;
• количество SQL-запросов на сценарий и их суммарное время;
• использование CPU, оперативной памяти, диска и сетевых соединений;
• число обращений к внешним API и их тайм-ауты.

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

Порядок рефакторинга

1. Зафиксируйте воспроизводимый сценарий. Запишите URL, параметры, состояние кэша и число параллельных пользователей. Без этого после изменения невозможно отличить улучшение от случайного колебания.
2. Разделите витринные и фоновые операции. Обновление остатков, синхронизацию цен, отправку событий и пересчёт больших наборов данных не стоит выполнять в запросе посетителя. Для них нужен отдельный механизм очереди или планировщика, совместимый с вашей инфраструктурой.
3. Уберите повторяющиеся чтения. Найдите запросы внутри циклов и объедините получение данных там, где это сохраняет корректность результата. Проверьте, что изменение не нарушает права доступа, валюты, скидки и остатки.
4. Проверьте индексы по планам выполнения. Добавляйте их под конкретные фильтры и сортировки, после чего повторяйте нагрузочный сценарий. Измеряйте и чтение, и запись.
5. Сведите модификации к понятным группам. Удалите неиспользуемые расширения, объедините дублирующие изменения и зафиксируйте порядок применения. Каждую группу проверяйте отдельно, а не после полного обновления магазина.
6. Настройте деградацию. Если сервис доставки недоступен, карточка товара не должна бесконечно ждать его ответа. Покажите сохранённые данные или отключите необязательный блок по тайм-ауту.

Граничные случаи, где план ломается

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

Увеличение PHP-FPM полезно только при наличии свободной памяти и запаса у базы. Если база уже занята, большее число процессов добавит конкуренцию за те же соединения. Если база свободна, а все воркеры ждут внешний API, оптимизировать нужно интеграцию, а не SQL.

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

Что проверять на ревью

Что делать дальше

Начните с одного самого дорогого пользовательского сценария, а не с полной переписи магазина. Снимите базовые метрики на OpenCart 3.x, разделите холодный и прогретый кэш, затем проверьте внешние вызовы, повторяющиеся SQL-запросы и очередь PHP-FPM именно в этом порядке.

После каждого изменения сохраняйте отчёт с теми же параметрами нагрузки. В продакшене отдельно наблюдайте 95-й перцентиль, долю 5xx, время SQL-запросов, число занятых PHP-воркеров и тайм-ауты интеграций. Инвалидация кэша и безопасная миграция базы — отдельные темы; здесь важна только связь этих механизмов с задержкой запроса.

Сноска. Перцентиль показывает значение, ниже которого находится заданная доля измерений: 95-й перцентиль времени ответа — это граница для 95 процентов запросов, а не среднее арифметическое.