Кеширование в MODX: как работает и что ломается

Что происходит с запросом к MODX

В MODX один и тот же URL может обрабатываться двумя разными способами. При попадании в кеш движок возвращает ранее собранный результат почти без повторного запуска парсера. При промахе MODX загружает ресурс, обрабатывает чанки, плейсхолдеры и сниппеты, формирует HTML и сохраняет результат для следующих запросов.

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

Кеш в MODX — не кнопка «сделать быстрее», а договор: вы разрешаете показывать готовый результат, пока не наступило событие для его обновления.

Материал относится к MODX Revolution 2.8.x и MODX 3.x. Названия пунктов админки и внутренние пути между ветками могут различаться, поэтому перед изменением конфигурации сверяйте документацию именно своей версии.

Какие данные кеширует MODX

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

• Кеш ресурса. Готовый результат страницы, связанный с ресурсом и контекстом. Он используется для документов, которым разрешено кеширование.
• Кеш элементов. Чанки, сниппеты и другие элементы могут сохранять результаты обработки. Это особенно заметно у тяжёлых сниппетов, которые вызываются на многих страницах.
• Кеш системных настроек и контекстов. MODX хранит служебные данные, чтобы не читать одни и те же настройки из базы при каждом запросе.

Поверх MODX могут работать другие слои: кеш браузера, CDN, reverse proxy, OPcache и кеш базы данных. Очистка кеша MODX не удаляет копию страницы из CDN и не перезапускает PHP-код в OPcache.

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

Как MODX проходит запрос по шагам

1. Определяется ресурс

MODX сопоставляет URL с ресурсом, его контекстом и настройками публикации. На этом этапе важны права доступа, статус публикации, дата публикации и параметр кешируемости ресурса.

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

2. Проверяется готовый результат

Для кешируемого ресурса движок ищет сохранённый результат. При попадании в кеш MODX не обязан заново выполнять весь набор сниппетов и собирать шаблон. Это сокращает нагрузку на PHP и базу данных.

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

3. Разбираются теги MODX

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

<!-- Значение может попасть в кеш страницы -->
[[!pdoResources? &parents=`5` &limit=`10`]]

<!-- Такой вызов выполняется при каждом запросе -->
[[!Login? &tpl=`loginForm`]]

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

4. Результат записывается в кеш

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

Кешируемый и некешируемый вызов

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

Почему данные остаются старыми

MODX не может автоматически угадать, что внешний источник изменил данные. Если сниппет получает цену из API, а его результат оказался в кешированном HTML, изменение цены в магазине не обязано немедленно обновить страницу.

Есть четыре типичных сценария.

1. Изменили ресурс, но не тот контекст. Сайт может использовать несколько контекстов, например для разных языков или доменов. Очистка одного контекста не всегда затрагивает другой.
2. Изменили данные в базе напрямую. MODX не получил событие об изменении и не знает, какие страницы теперь устарели.
3. Остался кеш внешнего слоя. В админке уже видна новая версия, а CDN или прокси продолжает отдавать старый ответ.
4. Динамический сниппет вызывается кешируемо. Сессионные, персональные и временные данные нельзя бездумно сохранять в общем кеше.

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

Где кеш ломается первым

Персональные блоки

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

Списки с фильтрами

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

Изменения через внешнюю систему

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

Как измерять эффект, а не угадывать

Сравнивайте один и тот же URL в двух состояниях: после очистки кеша и при повторном запросе. Фиксируйте время до первого байта, полное время ответа, число SQL-запросов и загрузку PHP. Замер проводите на той же версии PHP, с тем же объёмом данных и без параллельных изменений в базе.

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

При диагностике проверяйте цепочку целиком:

• страница действительно кешируемая;
• в шаблоне нет лишних некешируемых вызовов;
• сниппеты не выполняют тяжёлые запросы при каждом открытии;
• CDN и reverse proxy не отдают старую копию;
• после публикации изменённых данных запускается ожидаемое обновление.

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

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

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

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