Механизм работы кэша в umi — различия между версиями
VITL' (обсуждение | вклад) (Новая страница: « category:Архитектура UMI.CMS Umi.cms поддерживает различные кэширующие механизмы, допустим apc, eacc…») |
(нет различий)
|
Версия 20:35, 26 января 2011
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 – объект с $object_id = 27607, 32 – id поля, таблица в БД cms3_object_content.
697_object_type – тип данных с $type_id = 697, таблица cms3_object_types
Информация по архитектуре базы данных: Архитектура базы данных системы
Как вы уже заметили, в самом конце названий ключей используется одно и тоже значение длиной в 40 символов, при получении данного значения используется переменная salt, в конфигурационном файле, config.ini. salt'a генерируется автоматически при установке системы.
При редактировании данных в административной части или через edit-in-place, происходит обнуление данных в кэше, соответственно обнуление только необходимых данных, а не всего кэша.
При запросе каких либо данных, происходит проверка, не хранятся ли уже необходимые данные в кэше, если да, то происходит загрузка данных из кэша, без каких-либо запросов к базе данных.