Кеширование в MODx Revolution


В MODX Revolution вы можете не/кешировать любой используемый тег. Включая сниппеты, теги настроек, плейсхолдеры (заполнители), чанки и даже строки словаря. Эта статья раскроет некоторые идеи относительно того, когда вызывать кешируемое содержимое в MODX Revolution (но также не затронет все усилия, потраченные на внутреннее содержание).

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

Как задать в MODX (не)кешировать обычный тег?

Просто добавьте восклицательный знак напротив токена. Токен – это знак доллара для чанков ($), плюс (+) для плейсхолдеров (заполнителей), знак процента (%) для словаря и астерикс (*) для полей и дополнительных полей (переменных шаблона) ресурса. Сниппеты не имеют токена.

Примеры кешированных тегов:



Примеры некешированных тегов:



Четыре стратегии кеширования

  • Кешируйте всё, что только можно
    В основном  вы захотите кешировать как можно больше – зачем MODX извлекать весь контент из базы данных по каждому запросу, когда он не меняется? Пока это кажется логичным (и редко возникают вопросы кешировать поля ресурса или нет), тоже касается и других тегов. Если вывод сниппета не изменяется при каждом запросе – почему MODX парсит сниппет при каждом запросе? Он не должен это делать.
  • Специфические пользовательские выводы, которые не должны кешироваться.
    Всё, что выводит специфическую пользовательскую информацию и должно быть некешированным. Просто – любой запрос может быть сделан различными пользователями, поэтому не будет пользы от загрузки специфической пользовательской инфорации из кеша. Это применимо к сниппетам, которые взаимодействуют с системой пользователей (пакет Login, компонент пожеланий Wishlist и компонент для комментирования Quip), но также почему-то малоизвестный плейсхолдер [[!+modx.user.id]].
  • Контент связанный с URL параметрами или POST данными должен быть некешированный.
    Если вы используете форму или сниппет, который выводит информацию про то, что было опубликовано, вы не должны эту информацию зафиксировать и кешировать. Поэтому вызов должен быть некешируемым. Если ваш вывод отличается в зависимости от (не-id) URL параметров (например – страница результата работы поиска), то вы бы хотели убедится в том, что связанный с этим сниппет некешируемый.
  • Используйте пользовательское кеширование при необходиости.
    Если данные (в сниппете) изменяются перед тем, как кеш очищен, например, если данные извлекаются из внешнего XML ресурса, который изменяется независимо от вашего MODX контента, то вы заходите использовать пользовательский метод кеширования, такой как сниппет getCache или напишете ваш собственный метод всередине кода сниппета.

Исключения

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

site_url, http_host и связанные с системными настройками могут вызыватся как некешируемые. Если у вас стандартная установка, в которой одна комбинация ресурс+шаблон  может обслуживать множественные урлы, то вы захотите убедится в том, что связанные системные настройки вызываются как некешированные. Одно общее применение для этого это ваш тег <base href="[[!++site_url]]"> для ЧПУ: вы захотите убедится в том, что ваши объекты обслуживаются из того же домена, который посещают люди, зашедшие на сайт. Должны ли вы принудительно приводить базовый урл к виду www/без www через файл htaccess – это совсем другой вопрос, но он очень связан с данным и является основным источником проблем.

Сниппеты, которые (могут) делать редирект или направлять куда-либо будут нуждаться в некешированном виде и в результате могут быть пустыи, но обработка сниппета делает нужную работу и перенаправляет пользователя.

Общие ошибки

  • Некешируемый вызов сниппета "if", когда параметр subject – это поле ресурса. Скорее всего данная проблема вызвана наличием в документации примеров некешируемых вызовов, много народу неправильно используют сниппет If просто не кешируя его, когда предмет статичен на протяжении жизни кеша.
  • Некешируемый вызов сниппета "Wayfinder". Пожалуйста, не делайте этого! Wayfinder может сильно повлиять на быстродействие вашего сайта, особенно с большими меню. Единственной значимой причиной, которая приходит на ум, для использования некешированного вызова Wayfinder – это когда вывод зависит от пользователя (области «только для подписчиков», например).
  • Некешируемые плейсхолдеры в чанках, которые используются как шаблоны в сниппетах. Некешируемые плейсхолдеры обрабатываются в последнее возможное время и вызывая их некешируемыми в шаблоне – оставит их вне такта и они не будут заменены сниппетом, вместо этого парсером ядра намного после того, как сниппет закончит работу. (Это поведение вызывало некоторые изменения/баги в релизах 2.1.x, поэтому схожая ситуация может быть в последнем релизе).

Какие из описанных выше ошибок вы делали или обнаружили? Есть ли у вас другие тактики в кешировании? Ниже опишите, если таковые имеют место!

Оригинал статьи. Mark Hamstra. Caching Guidelines for MODX Revolution