Кэширование

Кэшируя повторно используемые данные, можно предотвратить множество запросов к базе данных, что приведет к повышению производительности. MODX Revolution предлагает ряд различных функций кэширования на разных уровнях в приложении. Кэширование в MODX в основном обрабатывается базовым классом modCacheManager, который расширяет класс xPDOCacheManager и позволяет использовать обработчики кэша, зависящие от раздела. Реализация по умолчанию записывает кэши в файлы в папке core/cache/.

Если вы определили пользовательский ключ MODX_CONFIG_KEY, менеджер кэша выполнит запись в core/cache/MODX_CONFIG_KEY/

Общая терминология кэширования и поведение¶

MODX использует разные разделы для отдельных типов кэшируемых данных. Упрощенно, раздел - это папка в директории core/cache/, но настоящая ценность разделов в том, что каждому разделу могут быть назначены разные обработчики кэша. Обработчики кэша являются производными от класса xPDOCache и предоставляют единый API для хранения, чтения и удаления записей кэша.

В ядре поставляются следующие обработчики кэша:

Файл xPDO\Cache\xPDOAPCCache присутствует в дереве исходного кода, но не может инициализироваться: он проверяет наличие apc_exists() — функции, удалённой в PHP 7. Не настраивайте его.

::: warning Обработчик, которому не удалось инициализироваться, заменяется на xPDOFileCache, и сайт продолжает работать, поэтому ошибку в настройке легко не заметить. Имя класса, которое не удалось загрузить, записывается в журнал MODX на уровне ERROR строкой Could not load class: ... — проверяйте журнал после смены обработчика. См. Использование Memcache. :::

Разделы основного кэша MODX¶

В ядре несколько разделов. Их можно легко определить, просмотрев папку core/cache/ с конфигурацией кэша по умолчанию.

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

Как мы обсудим позже, пользовательские провайдеры также могут быть использованы в разработке.

• auto_publish содержит метку времени Unix, которая определяет, когда ресурс должен быть автоматически опубликован или распубликован (см. ModCacheManager.autoPublish())
• context_settings для каждого контекста на сайте содержит карту ресурсов (идентификаторы родительских и дочерних документов), карту псевдонимов, используемые в контексте плагины и политики доступа.
• db раздел кэша базы данных используется, когда включена системная или контекстная настройка cache_db, и содержит необработанные наборы результатов для запросов xPDO getObject/getCollection. Подробнее об этом ниже.
• default раздел, в который попадает каждый вызов set() без xPDO::OPT_CACHE_KEY — поэтому ваши собственные кэшированные данные исчезают при очистке кэша сайта.
• lexicon_topics дерево тем лексикона, используется менеджером.
• media_sources определения источников медиа.
• menu cодержит для каждого языка менеджера многомерный массив верхнего меню менеджера.
• namespaces индекс пространств имён, включая пакеты, установленные через Extras.
• packages заполняется процессорами установки и удаления пакетов.
• resource содержит организованный по контексту и идентификатору ресурса механизм частичного кэширования ресурсов. Эти файлы кэша содержат метаданные для ресурса, кэшированное представление ресурса (_content) с оставшимися без кэширования тегами, политиками доступа к ресурсу и элементами и их источниками, используемые при обработке ресурса.
• scripts содержит подготовленный исходный код сниппетов и плагинов, записываемый как исполняемый PHP.
• system_settings содержит глобальную конфигурацию MODX и системные настройки. Этот раздел загружается первым по запросам в MODX. Поскольку альтернативные обработчики кэша для разделов хранятся в системных настройках, этот раздел не может быть загружен из другого обработчика кэша таким образом.

Ещё четыре директории лежат в core/cache/, но разделами кэша не являются:

• includes содержит подготовленный PHP статических сниппетов и плагинов, который записывает modScript::loadScript() для прямого подключения. Не раздел кэша.
• logs - это также не раздел кэша, но содержит файл error.log и иногда другие файлы журнала (например, журнал установки).
• registry используется классом modFileRegister — файловым хранилищем, через которое менеджер передаёт данные процессорам. Не раздел кэша.
• rss используется библиотекой SimplePie для кэширования лент виджета RSS на панели. Не раздел кэша.

Имя каждого раздела задаётся двумя системными параметрами: cache_PARTITION_key хранит имя папки, cache_PARTITION_handler — класс обработчика. Чтобы сменить обработчик одного раздела, создайте системный параметр с именем cache_PARTITION_handler — например, cache_resource_handler или cache_scripts_handler — и присвойте ему имя класса нужного обработчика. Контекстные параметры с тем же именем перекрывают системные, поэтому раздел можно перенести в другое хранилище только для одного контекста.

::: warning Параметр cache_resource_clear_partial переключает refresh() на очистку только названных вами контекстов вместо всего раздела resource. Он действует только тогда, когда cache_handler задан строго как xPDOFileCache: MODX сравнивает значение как буквальную строку, а его собственное значение по умолчанию — namespaced xPDO\Cache\xPDOFileCache. На практике нужно задать оба параметра вручную, иначе флаг игнорируется. :::

Обратите внимание, что в MODX 2.0.x система кэша довольно сильно отличалась. Доступные разделы были иными, а системные настройки сохранялись в core/cache/config.cache.php. Если вы все еще используете MODX 2.0.x, вам следует потратить больше времени на обновление и меньше времени на чтение этого документа.

Кэширование базы данных {#database-caching}¶

Если вы включите системный параметр cache_db, MODX может автоматически кэшировать наборы результатов базы данных, извлеченные любым экземпляром xPDOCriteria или xPDOQuery. Это включает в себя все наборы результатов, представляющие xPDOObjects или коллекции xPDOObjects, возвращаемые такими методами, как getObject и getCollection.

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

Результаты попадают в раздел db, который участвует в refresh() наравне с остальными и который можно перенаправить на другой обработчик:

Не путайте это с xPDOCriteria::$cacheFlag — отдельным механизмом, принадлежащим этому классу и не связанным с cache_db. Смотрите xPDO Caching для дополнительной информации.

Обновление кэша MODX Core¶

Чтобы обновить любой из основных разделов кэша MODX, используйте метод modCacheManager->refresh(). Минимальный вызов не имеет параметров и обновит все разделы основного кэша.

$modx->cacheManager->refresh();

Кроме того, вы можете определить массив $providers с разделом элементов key => $partitionOptions.

// Обновить только настройки контекстов web и web2
$modx->cacheManager->refresh([
    'context_settings' => ['contexts' => ['web', 'web2']],
]);

Второй параметр $results передаётся по ссылке и содержит результат по каждому разделу. Большинство разделов отдают логическое значение; context_settings отдаёт по одной записи на контекст. Метод возвращает false, если какой-либо раздел вернул строго false — раздел, вернувший null или 0, ошибкой не считается.

Каждое обновление также вызывает событие OnCacheUpdate со свойствами results, paths и options.

Программное (пользовательское) кэширование {#programmatic-caching}¶

Взаимодействуя с modCacheManager, вы можете легко кэшировать данные любого типа. Есть несколько полезных функций, которые вы можете использовать для поддержания рабочего кэша. Используя modCacheManager с пользовательским разделом (хотя и необязательно), пользователи вашего кода могут изменить обработчик кэша и сохранить данные в экземпляре memcached, Redis или WinCache вместо файлового кэша по умолчанию.

ModCacheManager (производный от xPDOCacheManager) предоставляет следующие полезные методы:

• add($key, &$var, $life = 0, $options = array()) используется для добавления значения в кэш, но только если оно еще не существует или срок его действия истек.
• replace($key, &$var, $life = 0, $options = array()) используется для замены существующего кэшированного значения другим.
• set($key, &$var, $life = 0, $options = array()) используется для установки значения в кэш независимо от того, существует ли оно уже (перезаписывается) или нет (добавляется).
• delete($key, $options = array()) удаляет кэшированное значение из кэша.
• get($key, $options = array()) получает кэшированное значение из кэша.
• clean($options = array()) очищает (удаляет) весь поставщик кэша. Убедитесь, что вы определили xPDO::OPT_CACHE_KEY в массиве параметров.
• flushPermissions() помечает данные прав всех пользователей устаревшими, чтобы они были перестроены при следующем запросе.

::: warning add(), replace() и set() объявляют $var по ссылке. Передайте им литерал напрямую — $modx->cacheManager->set('k', 5) — и PHP выдаст фатальную ошибку. Сначала присвойте значение переменной. :::

В общем случае вы можете использовать get($key) и set($key, $value) для получения и установки значений соответственно, но дополнительные методы обеспечивают дополнительный контроль над способом управления данными.

Массив $options может содержать следующие параметры, указывающие раздел кэша для записи, используемый обработчик кэша и время истечения по умолчанию.

• xPDO::OPT_CACHE_KEY - раздел кэша для записи.
• xPDO::OPT_CACHE_HANDLER - используемый обработчик кэша. Как правило, вам не нужно жестко определять этот параметр, но имеет смысл разрешать конкретной реализации обрабатывать обработчик кэша с помощью системных настроек (то есть системных настроек cache_PARTITION_handler).
• xPDO::OPT_CACHE_EXPIRES - время истечения по умолчанию.

Пример 1: Простое добавление и получение кэша¶

$str = 'Мои тестовые данные для кэша.';
// Записываем данные в раздел кеша по умолчанию со сроком действия 2 часа.
$modx->cacheManager->set('testdata', $str, 7200);

// Получаем данные из кеша снова. Возвращается ноль, если кеш недоступен или срок его действия истек.
$str = $modx->cacheManager->get('testdata');

Пример 2. Добавление и получение кэша из пользовательского раздела¶

$str = 'Мои тестовые данные для кэша.';
$options = array(
    xPDO::OPT_CACHE_KEY => 'mypartition',
);
// Записываем данные в раздел mypartition со сроком действия 2 часа.
$modx->cacheManager->set('testdata', $str, 7200, $options);

// Получаем данные из кеша снова. Возвращается ноль, если кеш недоступен или срок его действия истек.
$str = $modx->cacheManager->get('testdata', $options);

Замена менеджера кэша¶

MODX берёт класс менеджера кэша из системного параметра modCacheManager.class, а если он не задан — из встроенного modCacheManager. Укажите там свой класс, чтобы добавить разделы или изменить поведение refresh():

class MyCacheManager extends modCacheManager {
    public function refresh(array $providers = [], array &$results = []) {
        $cleared = parent::refresh($providers, $results);
        $this->modx->log(modX::LOG_LEVEL_INFO, 'Cache refresh finished.');

        return $cleared;
    }
}

Обратите внимание в Revolution 2.0¶

В MODX 2.0.x система кэша заметно отличалась: набор разделов был иным, а системные настройки хранились в core/cache/config.cache.php.

Метод modCacheManager->clearCache() по-прежнему существует, но устарел начиная с MODX 2.1 в пользу refresh(). Не используйте его в новом коде.

Смотрите также¶

• Базовое использование — запись и чтение значения из сниппета
• Время жизни — сколько остаётся кэшированное значение действительным
• Использование Memcache — перенос раздела в memcached
• xPDO Caching — кэширование внутри самого xPDO