Modx автоматическая очистка кэша

Обновлено: 03.07.2024

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

В MODX управление кэшированием разделено на 3 уровня — административный, пользовательский и программный. Я хотел бы подробнее рассмотреть последний. Тем более это актуально при использовании подхода программирования, описанного в прошлой статье. Поэтому по первым двум пробежимся быстренько.

Итак, за первый уровень отвечает администратор сайта. Он настраивает кэширование для всего сайта. Делается это в системных настройках: раздел — core, подраздел — кеширование.

На пользовательском уровне кэширование уже настраивается для каждого ресурса и элемента (чанка, сниппета, плейсхолдера) в отдельности. У ресурса есть специальный чекбокс «Кешируемый». Если его отключить, то страница кэшироваться не будет. А для отключения кэширования элементов используется специальный флаг — восклицательный знак, который добавляется в тег перед названием элемента:

А вот теперь давайте подробнее остановимся на программном уровне. MODX использует разные разделы (partitions) для хранения разных типов данных. Разделы — это подпапки в папке core/cache/ . Вот их список:

  • action_map
  • auto_publish
  • context_settings
  • default
  • includes
  • lexicon_topics
  • logs
  • menu
  • namespaces
  • mgr
  • registry
  • resource
  • rss
  • scripts
  • system_settings

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

Информация!

В MODX есть крутая возможность указывать для каждого раздела свой провайдер (handler). По-умолчанию, MODX использует файловый менеджер xPDOFileCache. Но кроме него доступны и другие провайдеры — xPDOAPCCache (для APC), xPDOMemCache (для memcache), xPDOMemCached (для memcached) и xPDOWinCache (для WinCache).

Чтобы указать другой провайдер для конкретного раздела, нужно создать системную настройку с названием cache_НАЗВАНИЕ_РАЗДЕЛА_handler и указать соответствующий класс провайдера. Например, чтобы подключить APC менеджер для ресурсов, создаём настройку cache_resource_handler и указываем в ней класс xPDOAPCCache.

Также для каждого раздела можно указать и другие настройки — cache_НАЗВАНИЕ_РАЗДЕЛА_key и cache_НАЗВАНИЕ_РАЗДЕЛА_expires.

Давайте рассмотрим как сохранять и получать свои данные в кэше. Для этого у кэш менеджера MODX (класс modCacheManager ), который наследуется от базового класса xPDOCacheManager , есть соответствующие методы — get() , set() , delete() и refresh() . Начнём с самого простого.

Если зайти в папку core/cache/default/ , то можно увидеть созданный файл userdata.cache.php , в котором хранится массив с данными пользователя. Если раздел не указан (как в нашем случае), то данные сохраняются в папку default .

Теперь давайте ограничим время хранения наших данных.

Но всё-таки удобнее хранить пользовательские данные в специальной папке (разделе). Для этого нужно указать соответствующий параметр cache_key .

Теперь в папке core/cache/ создалась папка users_data и в ней появляются файлы типа 1.cache.php , 5.cache.php и т.д. Т.е. теперь для каждого пользователя создается свой кэш с данными.

Если нужно удалить из кэша данные конкретного пользователя, то для этого используется метод delete()

А вот чтобы очистить весь кэш или целый раздел используется метод refresh() .

Информация!

Имейте ввиду, что папка default полностью очищается при каждом сохранении ресурса, чанка, сниппета и плагина.

Вот в общем-то и всё. Полученные знания вы можете применять для кэширования файловых элементов.

Уже когда-то задавался этим вопросом, пришел к такому решению (уже без getCache, но с fenom и включенным pdotools_fenom_parser).

UPD Зачем вообще это.

Создаем сниппет differenceBetweenDatesInSeconds:

На странице, где вызывается кэшируемый сниппет, пишем:

Потом cron-ом заходим на страницу каждый вторник в, например, 3:05 утра, тут уже сами гуглите.

Если у кого-то есть более элегантное решение, кидайте в комменты.

Комментарии: 31

Не совсем понял, а какую проблему решает данный сниппет?

Смысл в быстродействии.

У меня так: есть огромная страница, которую нужно спарсить раз в неделю и парсинг занимает много времени, если парсить каждый раз по окончанию действия кэша или ручной очистки кэша с админки, первому посетителю придется ждать десятки секунд (а он не будет ждать). Решил я парсить её cron-ом раз в неделю отдельным php скриптом, результат сохранять в файл на сервере (около 0.5 мб). Таким образом сниппет «snippetName» с примера выше, просто выполняет чтение и возврат этого файла «echo file_get_contents($file);», что существенно ускоряет время загрузки страницы если я очистил кэш вручную или время кэша закончилось. Потом я cron-ом выполняю запуск того самого php скрипта, который сохраняет результат в локальный файл. Вот такой вот многослойный торт.

а не проще сделать выполняемый с периодичностью по крону php скрипт который парсит данные и записывает результат в контент ресурса или допустим в тв поле?

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

когда обработка данных закончится он мигом запишет данные в ресурс и пользователь получит актуальную информацию.
разве после того, как записать результат в контент ресурса, не нужно будет очистить кэш этого ресурса, после этого обновить кэш этого ресурса, чтобы пользователь получил обновленную инфу? поидеи менеджер кэша должен отловить изменения и инфа при обновлении данных будет показываться актуальная, проверь, ну в любом случае, даже если у тебя по каким то причинам инфа будет кэшироваться, то после обновления данных можно почистить кэш, это всё равно лучше чем свой вариант велосипеда изобретать.
  1. результат парсинга заносим в контент; ;
  2. для обновления кэша пользователь должен зайти на страницу и получить задержку в несколько секунд (в моём случае), вместо этого мы заходим на страницу кроном.

ну если ты считаешь, что данный подход лучше чем использовать методы modx, ок.

я в этом ничего полезного к сожалению не увидел


для нубов в modx, php или вообще программировании, типа меня, это будет полезным
Проверил save(true) не работает :-(
А где делается кеш при загрузке странице в упор не могу найти

Эх, молодежь. Всё делается гораздо проще. Ставим modHelpers и используем функцию snippet.

А в cron удаляем кэш и парсим страницу сниппетом
Что важно! В данном случае сам сниппет на странице вызывается некэшированным. Поэтому кэш самой страницы обновлять не нужно. Только кэш сниппета. Обратите внимание, насколько код стал проще.

Функция snippet() сама проверит кэш. Если его нет, то выполнит указанный сниппет и результат сохранит в кэш. И не нужно вычислять все эти секунды. Cron каждую неделю будет обновлять кэш независимо от того, есть он или нет. Поэтому сниппет differenceBetweenDatesInSeconds не нужен. И даже вреден. Ибо делает ненужную работу для каждого запроса страницы.

П.С. И ещё совет. Не пихайте логику во вьюхи. Это бад практис! Перенесите логику в сниппет и вызывайте его на странице.

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

MODX - Время генерации страницы с использованием кэша

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

MODX - Как работает кэширование

Рассмотрим пример. Допустим у вас на всех страницах сайта в сайдбаре есть блок "Последние статьи". Для того чтобы его вывести на страницу вам необходимо подготовить запрос, получить данные из базы и обработать их. Вся эта операция не происходит мгновенно, на её выполнение требуется время. А если у вас в сутки запрашивается не одна, а сотни или тысячи страниц. То, представьте, сколько раз заново приходится строить один и тот же блок, т.е. при каждом запросе страницы, на которой он есть. Правильно конечно было бы создать блок "Последние статьи" только один раз (при первом вызове) и сохранить его кэш. А затем (при следующих запросах) просто использовать его. Тем самым можно не только увеличить быстродействие (загрузку) страниц, но и значительно уменьшить нагрузку на процессор и сервер баз данных. Последнее действие, которое ещё останется осуществить - это определить момент обновления кэша этого блока. В данном случае в момент выхода (публикации) новой статьи.

Как кэширование организовано в MODX Revo

По умолчанию кэш в CMS MODX Revolution находится в файлах и расположен в директории core/cache/ .

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

Раздел - это кэш с данными определённого вида (например, ресурсами). Раздел можно представить как директорию в каталоге core/cache/ .

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

Например, одним разделам кэша можно назначить провайдер xPDOFileCache , а другим xPDOMemCache .

В MODX Revolution доступны следующие провайдеры: xPDOFileCache (по умолчанию), xPDOAPCCache (для Alternative PHP Cache), xPDOMemCache (для memcache), xPDOMemCached (для memcached), xPDOWinCache (для WinCache).

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

Кэш менеджеры ( xPDOFileCache , xPDOAPCCache , xPDOMemCache , xPDOMemCached и xPDOWinCache ) являются производными от класса xPDOCache и предоставляют единую API для записи, чтения и удаления кэш записей.

Основные разделы кэша и их краткое описание

MODX Revolution имеет следующие разделы (справочная информация):

action_map Содержит массив всех идентификаторов контроллеров и пространств имён, доступных в менеджере. auto_publish Содержит штамп времени, который определяет момент, при наступлении которого необходимо будет автоматически опубликовать ресурс или снять его с публикации. context_settings Этот раздел используется для хранения настроек контекстов. Каждый контекст в этом разделе имеет свой файл, в котором содержится карта ресурсов (идентификаторы родителей и детей), карта псевдонимов, плагины, используемые в контексте и политика доступа. db Раздел кэша db предназначен для хранения результирующих наборов, запрошенных из базы данных с помощью методов getObject , getCollection и т.п. Этот кэш используется при включении параметра cache_db в настройках системы или тогда, когда данный параметр активирован в настройках контекста.
Этот кэш обычно применяется тогда, когда доступ к базе является более затратным действием, чем использование процессорного времени. includes Данный раздел используется как временное хранилище для исходных кодов php файлов (сниппетов и плагинов). Используется ядром MODX во время их выполнения. Файлы в этом кэше имеют формат: 23.include.cache.php (23 - это id сниппета или плагина). logs Данный раздел используется в качестве хранилища log файлов системы. menu Этот раздел содержит кэш меню менеджера (админки). mgr Данный раздел использует Smarty в качестве своего хранилища для записи в него временных файлов. resource Содержит кэш ресурсов, организованный с учётом контекста и id (файлы в этом кэше имеют формат 7.cache.php (7 - это id ресурса)). Каждый файл содержится метаданные ресурса, его кэшированное представление с не кэшированными тегами (_content), политику доступа для ресурса и элементов, а также их исходные коды (используются в процессе обработки ресурса). rss Данный раздел использует MagpieRSS в качестве каталога для записи своих временных файлов. scripts Содержит исходные коды сниппетов и плагинов, которые впоследствии будут записаны в кэш директорию includes . setup Используется системой MODX при установке. system_settings Содержит настройки системы MODX. Этот раздел загружается первым. Для его обработки нельзя назначить альтернативный кэшер (т.е. всегда используется только xPDOFileCache ).

Чтобы изменить провайдер кэша для определенного раздела кэша, просто создайте новый системный (или контекстный) параметр с именем cache_PARTITION_handler (например, cache_resource_handler - для раздела resource ) и присвойте ему значение обработчика кэша, который вы хотите использовать для его обработки (например, xPDOMemCache ).

Настройка кэширования в MODX Revo

В MODX Revolution управление кэшированием может осуществляться посредством:

  • изменения значений системных настроек (область действия - весь сайт);
  • кэшированного или не кэшированного (с восклицательным знаком) вызова чанков, сниппетов и плейсхолдеров (область действия - указанный элемент);
  • установки или снятия флажка в поле ресурса "Кэшируемый" (область действия - указанный ресурс);
  • методов modCacheManager (программное управление кэшированием).

Управление кэшированием посредством изменения системных настроек

Общие настройки кэширования, влияющие на весь сайт, устанавливаются в системных настройках. Для этого необходимо нажать в админке MODX (в главном меню) на значок шестерёнки -> выбрать пункт "Системные настройки" -> раздел "Core" -> подраздел "Кэширование".

MODX - Системные настройки кэширования

Название ключей и их назначение:

cache_action_map (по умолчанию: да) Включает кэширование карты контроллеров (для ускорения загрузки страниц панели управления). cache_alias_map (по умолчанию: да) Включает кэширование карты ресурсов (добавление URI ресурсов в кэш контекста). Эту опцию рекомендуется устанавливать в положение "Да" только для небольших сайтов. А для сайтов с огромных количеством ресурсов её отключать. cache_context_settings (по умолчанию: да) Включает кэширование настроек контекстов для более быстрой загрузки страниц. cache_db (по умолчанию: нет) При включении, объекты и необработанные результаты наборов, запрашиваемые посредством SQL запросов будут кэшироваться (используется для уменьшения нагрузки на базу данных). Для хранения этого кэша может потребоваться достаточно большой объём дискового пространства. cache_db_expires (по умолчанию: 0) Время (в секундах) для хранения кэша db. Если установить значение, равное 0, то время жизни кэша будет не ограниченным. cache_db_session (по умолчанию: нет) При включении данной опции и cache_db, сессии, хранящиеся в базе данных, тоже будут кэшироваться. cache_db_session_lifetime (по умолчанию: нет) Время (в секундах), которое определяет период жизни кэша сессий. cache_default (по умолчанию: да) Устанавливает, необходимо ли при создании ресурса, делать его кэшируемым (устанавливать флажок cacheable в положение "Да"). cache_disabled (по умолчанию: нет) Если установить данному параметру значение "Да", то он отключить весь механизм кэширования MODX Revolution (не рекомендуется). cache_expires (по умолчанию: 0) Это значение (в секундах) устанавливает время жизни кэша MODX. Значение 0 задаёт неограниченное время его жизни. cache_format (по умолчанию: 0) Формат хранения кэша. 0 - в формате массива PHP, 1 - в JSON, 2 - в сериализованном виде. cache_handler (по умолчанию: xPDOFileCache) Имя провайдера, используемого по умолчанию для обработки всех разделов кэша. cache_lang_js (по умолчанию: да) При включении данной опции будут использоваться серверные заголовки для кэширования строк лексикона загружаемые в JavaScript и используемые интерфейсом менеджера. cache_lexicon_topics (по умолчанию: да) Когда включено, все темы словарей будут кэшироваться. Это позволит значительно снизить нагрузку при интернациональном использовании системы. MODX рекомендует оставлять эту опцию включенной, иначе работа менеджера может быть сильно замедлена. cache_noncore_lexicon_topics (по умолчанию: да) При отключении данной опции темы словарей дополнений (не принадлежащих ядру) кэшироваться не будут. Эта опция может быть очень полезна при разработке дополнений. cache_resource (по умолчанию: Да) Включает частичное кэширование ресурсов. Будут задействованы только те ресурсы, у которых параметр "Кэшируемый" установлен. Выключение данной опции отключит кэширование всех ресурсов. cache_resource_expires (по умолчанию: 0) Устанавливает период жизни кэша ресурсов (в секундах). Значение 0 позволяет хранить кэш ресурсов неограниченное время. cache_scripts (по умолчанию: да) Если включено, то MODX будет кэшировать все скрипты (сниппеты и плагины) в кэш (файлы) для увеличения скорости их загрузки. MODX рекомендует оставить эту настройку включённой. cache_system_settings (по умолчанию: Да) Если выбрано "Да", то настройки системы будут кэшироваться, тем самым уменьшая время загрузки страниц. MODX рекомендует оставить эту настройку включённой, т.е. в положение "Да". clear_cache_refresh_trees (по умолчанию: Нет) Если включено, то после обновления кэша сайта активные древовидные меню менеджера будут автоматически обновляться. syncsite_default (по умолчанию: Да) Если параметр имеет значение "Да", то сохранение ресурса будет приводить к автоматической очистке кэша.

Настройка кэширования ресурсов

В MODX управление кэшированием ресурсов осуществляется:

  • посредством изменения системных настроек cache_resource , cache_resource_expires и cache_default (глобальные настройки, влияющие на все ресурсы);
  • с помощью флажка "Кэшируемый" (включает или отключает кэш отдельно взятого ресурса).

Кэш ресурсов в MODX расположен в директории /core/cache/resource/ . Он построен с учётом контекста, к которому принадлежит ресурс. Имена файлов в этом кэше имеют следующий формат:

Цифра в начале имени - это значение id ресурса.

Управление кэшированием элементов

Система MODX позволяет управлять кэшированием чанков, сниппетов и плейсхолдеров. Осуществляется это посредством флага (восклицательного знака) в конструкции вызова этого элемента.

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

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

Программное управление кэшированием

В MODX работа с кэшем осуществляется посредством modCacheManager , который является расширением класса xPDOCacheManager .

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

  • add($key, $var, $lifetime = 0, $options = array()) - необходим для добавления значения в кэш (но только если это значение не существует или срок его хранения вышел);
  • replace($key, $var, $lifetime = 0, $options = array()) - используется для замены одного (существующего) кэшированного значения на другое;
  • set($key, $var, $lifetime = 0, $options = array()) - используется для установки значения в кэш не зависимого от того есть ли оно в кэше или нет;
  • delete ($key, $options = array()) - удаляет кэшированное значение из кэша;
  • get ($key, $options = array()) - применяется для получения кэшированное значение из кэша;
  • refresh ($key, $options = array()) - предназначен для удаление всех разделов кэша или какого-то конкретного.

Массив $options может содержать следующие ключи:

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

Примеры использования методов modCacheManager :

Удаление всего кэша MODX:

Удаление кэша контекстов web и en из раздела context_settings :

Получить значение кэша по ключу comments_17 из раздела comments :

Сохранить в кэш comments_17 , расположенный в разделе comments , значение переменной $output (время хранения данных в кэше не ограниченное):

Удалить из раздела main_menu кэш menu_11 :

Пример, как можно организовать программное кэширования главного двухуровневого меню на сайте, выполненного с помощью компонента navbar Bootstrap 3.

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

Чанк tpl.mainMenuOuter (внешняя обёртка главного меню):

Вызов сниппета MainMenu в шаблоне:

После этого в разделе main_menu будет находиться кэши главных меню ресурсов.

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

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

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

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

Обработчик кэша по умолчанию xPDOFileCache записывает кэш в файловую систему в папке core/cache/ , но в ядре доступны также другие обработчики кэша для APC ( xPDOAPCCache ), memcache(d) ( xPDOMemCache , xPDOMemCached ) и WinCache ( xPDOWinCache ).

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

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

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

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

  • action_map содержит большой массив всех действий (идентификаторов, ссылающихся на контроллеры и пространства имен), которые могут быть доступны в менеджере. Поскольку действия устарели и больше не используются в 2.3, никогда не полагайтесь на них.
  • auto_publish содержит метку времени Unix, которая определяет, когда ресурс должен быть автоматически опубликован или распубликован (см. ModCacheManager.autoPublish() )
  • context_settings для каждого контекста на сайте содержит карту ресурсов (идентификаторы родительских и дочерних документов), карту псевдонимов, используемые в контексте плагины и политики доступа.
  • db раздел кэша базы данных используется, когда включена системная или контекстная настройка cache_db , и содержит необработанные наборы результатов для запросов xPDO getObject / getCollection . Подробнее об этом ниже.
  • includes - на самом деле, это не раздел кэша, но он содержит файлы PHP, где сниппеты и плагины заключены в вызовы функций для легкого выполнения ядром. Смотрите сценарии для раздела кэша для сниппетов и плагинов.
  • logs - это также не раздел кэша, но содержит файл error.log и иногда другие файлы журнала (например, журнал установки).
  • menu cодержит для каждого языка менеджера многомерный массив верхнего меню менеджера.
  • mgr не является настоящим разделом кэша, но используется Smarty и Google Minify в 2.2 для записи файлов кэша.
  • registry - это директория по умолчанию для modRegistry, в которую записываются журналы регистрации файлов. Не является настоящим разделом кэша.
  • resource содержит организованный по контексту и идентификатору ресурса механизм частичного кэширования ресурсов. Эти файлы кэша содержат метаданные для ресурса, кэшированное представление ресурса (_content) с оставшимися без кэширования тегами, политиками доступа к ресурсу и элементами и их источниками, используемые при обработке ресурса.
  • rss не является настоящим разделом кэша, но используется MagpieRSS (виджеты RSS панели) для записи в кеш.
  • scripts содержит источник сниппетов и плагинов, которые впоследствии записываются в папку кэша includes.
  • setup не является настоящим разделом кэша, но используется инсталлятором MODX для кэширования шаблонов Smarty.
  • system_settings содержит глобальную конфигурацию MODX и системные настройки. Этот раздел загружается первым по запросам в MODX. Поскольку альтернативные обработчики кэша для разделов хранятся в системных настройках, этот раздел не может быть загружен из другого обработчика кэша таким образом.

Чтобы изменить обработчик кэша для определенного раздела кэша, просто создайте новый системный (или контекстный) параметр с именем cache_PARTITION_handler (например, cache_resource_handler или cache_scripts_handler ) и присвойте ему значение обработчика кэша, который вы хотели бы использовать. По умолчанию используется xPDOFileCache , однако и другие обработчики доступны для APC , memcache (d) и wincache .

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

Кэширование базы данных¶

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

Эта функция может быть включена в средах, где доступ к базе данных обходится дороже, чем время подключения файлов PHP, например, при использовании внешнего сервера базы данных, или настраивается для сред с доступным memcached , APC или другими системами кэширования. Это отдельный раздел кеша в MODX, поэтому его можно настроить с другими обработчиками кэша. Смотрите xPDO Caching для дополнительной информации.

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

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

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

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

Программное (пользовательское) кэширование¶

Взаимодействуя с modCacheManager , вы можете легко кэшировать данные любого типа. Есть несколько полезных функций, которые вы можете использовать для поддержания рабочего кэша. Используя modCacheManager с пользовательским разделом (хотя и необязательно), пользователи вашего кода могут изменить обработчик кэша и сохранить данные в экземпляре memcached , APC или 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 в массиве параметров.

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

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

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

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

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

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

В MODX Revolution 2.0 была другая система кеширования с отличающимися разделами. Чтобы очистить кеш в 2.0, вы должны использовать метод clearCache() , который устарел с 2.1. Лучше обновиться до последней версии, чем продолжать использовать 2.0.

Разработано, построено и написано со всей любовью в мире от сообщества MODX.

Читайте также: