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

Когда магазин на OpenCart начинает отдавать 502, медленно открывать каталог или терять корзину, проблема редко сводится к отсутствию кеша. В OpenCart 3.0.x кешируются отдельные результаты работы приложения, а HTML-страница, запросы к базе, сессия покупателя и внешние API продолжают жить по своим правилам. Поэтому под нагрузкой сначала ломается не «кеш вообще», а конкретный участок цепочки: база данных, PHP-FPM, файловая система или конкурентное обновление одного и того же ключа.

Что именно кеширует OpenCart 3.0.x

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

Такой механизм полезен для повторяющихся данных каталога, настроек, схем и других результатов, которые не нужно вычислять на каждый запрос. Но он не отменяет работу PHP и не делает страницу статической. Каждый запрос по-прежнему проходит через веб-сервер, PHP и код OpenCart, если поверх магазина не установлен отдельный reverse proxy или полнотекстовый page cache.

Драйвер кеша в OpenCart 3.0.x выбирается конфигурацией и зависит от сборки, хостинга и установленных расширений PHP. Встречаются файловое хранилище, Memcached и Redis, но конкретный набор нельзя переносить между серверами без проверки конфигурации и документации вашей версии.

Кеш уменьшает цену повторного чтения данных. Он не уменьшает количество ошибок в запросах к базе, не добавляет PHP-воркеры и не защищает магазин от всплеска уникальных запросов.

Промах кеша^[1] — ситуация, когда нужного значения нет в хранилище или оно просрочено. В этот момент запрос выполняет дорогую операцию заново.

Что происходит под нагрузкой

1. База данных становится первым ограничителем

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

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

2. PHP-FPM заканчивает свободные воркеры

Кешированный результат всё равно нужно получить через PHP, если не используется кеширование готового HTML. При медленном запросе к базе или внешнему сервису воркер дольше остаётся занятым. Очередь растёт, а пользователи видят увеличивающееся время ответа, 504 или 502.

Проверяйте число занятых и свободных PHP-FPM-воркеров, время ожидания в очереди и пиковое потребление памяти. Увеличивать лимит воркеров без проверки RAM опасно: сервер может перейти в swap и стать медленнее.

3. Файловый кеш упирается в I/O

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

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

4. Все запросы одновременно начинают прогревать один ключ

После очистки кеша или истечения срока жизни популярного ключа несколько запросов могут одновременно пойти за одним результатом. Каждый выполняет тяжёлый запрос к базе, а затем пытается записать одинаковое значение. Это называют cache stampede — лавиной промахов кеша.

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

Сравнение вариантов хранения

Таблица описывает классы решений, а не обещает одинаковое поведение в каждой сборке. Перед переключением проверьте, поддерживает ли конкретная версия OpenCart выбранный драйвер, установлен ли нужный модуль PHP и доступен ли сервис с веб-сервера.

Что измерить до изменения конфигурации

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

1. Зафиксируйте базовую линию. Запишите p50, p95 и p99 времени ответа, долю ошибок, число запросов в секунду и потребление памяти. Тестируйте на конкретной версии OpenCart, PHP, MySQL и драйвера кеша.
2. Сравните холодный и тёплый кеш. Холодный тест начинайте после очистки кеша, тёплый — после серии повторных запросов. Большая разница между ними указывает на дорогой прогрев или слишком низкую долю попаданий.
3. Посмотрите на базу. Сопоставьте время HTTP-запроса с временем SQL, количеством соединений и медленными запросами. Если PHP ждёт базу, смена файлового кеша на Redis сама по себе проблему не устранит.
4. Проверьте параллельность. Увеличивайте число одновременных клиентов постепенно и отмечайте точку, где растут p95, ошибки или очередь PHP-FPM. Не делайте вывод по одному короткому прогону.
5. Повторите тест после изменения одного параметра. Меняйте только драйвер, срок жизни, лимит памяти или число воркеров. Иначе вы не поймёте, что именно дало результат.

Граничные случаи: где кеширование ломается

Персональные данные попадают в общий результат

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

Изменение товара не обновляет все связанные ключи

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

Кеш скрывает проблему базы

На тёплом кеше магазин выглядит быстрым, но после деплоя, перезапуска Redis или массового истечения TTL нагрузка возвращается. Если запрос нельзя выполнить за приемлемое время без кеша, ищите индексы, лишние JOIN, сортировки и неоптимальные расширения, а не только новый драйвер.

Общее хранилище недоступно

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

Что ревьюить в рабочем проекте

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

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

Начните с одного сценария — например, карточки товара — и снимите профиль холодного и тёплого кеша. Затем найдите первый ресурс, который достигает лимита: SQL, PHP-FPM, диск, память или сеть. Только после этого выбирайте между файловым драйвером, Redis, Memcached и кешем HTML.

Для OpenCart 4.x не переносите настройки и ожидания из OpenCart 3.0.x вслепую: проверьте структуру конфигурации, доступные драйверы и совместимость расширений с вашей версией. В проде после изменения смотрите не только среднее время ответа, но и p95/p99, долю промахов кеша, ошибки 5xx, состояние PHP-FPM и медленные запросы MySQL.

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