Механизм работы кэша в umi

Umi.cms поддерживает различные кэширующие механизмы, допустим apc, eaccelerator. В данной статье будет описан принцип работы кэша APC, все остальные типы действуют по аналогичной схеме. Основной php класс, который выполняет функции управления кэшем находится в файле:

/classes/system/subsystems/cache/cacheFrontend.php. 

Если на хостинге подключен один из поддерживаемых системой кеширующих механизмов:

• apc
• eaccelerator
• xcache
• memcached

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

\classes\system\subsystems\models\data\
\classes\system\subsystems\models\hierarchy\
\classes\system\subsystems\streams\

происходит вызов методов из класса cacheFrontend, допустим:

$cacheFrontend = cacheFrontend::getInstance();
$cacheFrontend->save($element, "element");

метод getElement() в классе umiHierarchy.

В классе cacheFrontend, определяется текующий тип кэша, при вызове метода save() класса cacheFrontend, и включенном АРС, происходит вызов метода saveObjectData() в классе apcCacheEngine, файл:

\classes\system\subsystems\cache\engines\apc.php

В классе apcCacheEngine используются стандартные функции APC по сохранению данных, чтению, удалению и очистки всего кэша:

• apc_store
• apc_fetch
• apc_delete
• apc_clear_cache

Боле подробно ознакомиться с данными функциями и настройками APC можно на официальном сайте php.net

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

27612_object__3e53ea3115e961f8b4a2c2125a4dfcca8f45efde
50_element__3e53ea3115e961f8b4a2c2125a4dfcca8f45efde
8873_field__3e53ea3115e961f8b4a2c2125a4dfcca8f45efde
27607.32_property__3e53ea3115e961f8b4a2c2125a4dfcca8f45efde 
697_object_type__3e53ea3115e961f8b4a2c2125a4dfcca8f45efde

27612_object – начальная информация об объекте с $object_id = 27612, в самой umi, в базе данных это таблица cms3_objects.

50_element – данные о страницы с $page_id = 50, таблица cms3_hierarchy.

8873_field – информация о поле c id=8873, таблица cms3_object_fields.

27607.32_property – объект с $object_id = 27607, 32 – id поля, таблица в БД cms3_object_content.

697_object_type – тип данных с $type_id = 697, таблица cms3_object_types

Информация по архитектуре базы данных: Архитектура базы данных системы

Как вы уже заметили, в самом конце названий ключей используется одно и тоже значение длиной в 40 символов, при получении данного значения используется переменная salt, в конфигурационном файле, config.ini. salt'a генерируется автоматически при установке системы.

Возможны также следующие префиксы для ключей:

• 1_domain – домен системы, таблица cms3_domains
• 1_lang – язык системы, таблица cms3_langs
• 2_template – шаблон системы (XSL или TPL), таблица cms3_templates
• 7_field_type – тип поля, таблица cms3_object_field_types
• 24_element_type – иерархический тип объекта, таблица cms3_hierarchy_types

При редактировании данных в административной части или через edit-in-place, происходит обнуление данных в кэше, соответственно обнуление только необходимых данных, а не всего кэша.

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

В том же классе umiHierarchy, в файле \classes\system\subsystems\models\hierarchy\umiHierarchy.php, в методе getElement(), происходит загрузка данных из кэша:

$cacheFrontend = cacheFrontend::getInstance();
$element = $cacheFrontend->load($element_id, "element");

сначала запускается метод load() класса cacheFrontend, а потом запускается метод loadObjectData($key) текущего класса кэша, для apc: /engines/apc.php