Fi1osof 22 февраля 2015 5 6
Как я и писал в прошлом топике, занимаюсь новостным порталом, а требования к производительности и т.п. весьма повышенные, потому и много нетривиальных задач здесь, и как следствие — много всяких полезных заметок, описывающих решение этих задачек. Вот еще одна, довольно интересная. Она сама по себе совсем мелкая — просто системная настройка cache_prefix, но на освоение ее ушло довольно много часов. И вот еще пару часов на нее потратил и сегодня. Слишком много тонкостей с этим MODX-кешированием…

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

Как правильно.
1. cache_prefix как и cache_handler (если он был изменен) недостаточно прописать только в системных настройках.
Почему? Потому что в момент инициализации MODX-а, когда он еще только подгружает системные настройки и т.п. (которые, как известно, сохраняются с указанным кеш-префиксом и указанным кеш-провайдером (настройка cache_handler)), MODX еще ничего «не знает» про эти настройки. То есть тут замкнутый круг — «я не могу подгрузить настройки с кеш-префиксом, чтобы узнать какой кеш-префикс используется, чтобы нормально подгружать кеш»:) По этой причине каждый раз при обращении к сайту, MODX будет инициализироваться сначала проверив конфиги и кеш с базовым кеш-провайдером и префиксом, и лишь только подгрузив все и «поняв», что ему оказывается надо использовать другой кеш-провайдер и кеш-префикс, он начнет уже использовать их. А это хоть и не большая, но все-таки потеря производительности. Плюс еще и серьезные коллизии при сбросе кеша.

Поэтому MODX-у надо указать эти параметры явно и сразу, и лучше места я не нашел, кроме как в сам конфиг core/config/config.inc.php. Там есть пустой массив $config_options = array (); Вот и записываем там примерно вот так:
$config_options = array (
    'cache_handler' => 'cache.xPDOMemCached',
    'cache_prefix' => 'my_cache_prefix/',
);

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

2. cache_prefix обязательно должен заканчиваться на слеш /
Вот как раз на это я и потратил сегодня еще два часа… Раньше я просто писал типа cache_ (то есть с окончанием на подчеркивание) и не парился, вроде как все работало. Но сегодня обратил внимание на то, что вроде кеш сайта в целом сбрасывает, а вот кеш документов нет. Довольно серьезно пришлось покопаться, прежде чем я выяснил, что неправильно формируется путь до кеш-раздела документов. У меня, к примеру, префикс my_prefix_, и путь до раздела формировался не cache/resource/my_prefix_/web, а cache/resource/my_prefix_web (или типа того). В общем, коллизия происходила из-за того, что когда документ при запросе отрабатывается и MODX пытается его сохранить в кеш, MODX получает кеш-ключ ресурса, формируемый его методом getCacheKey(), при этом используется маска [contextKey]/resources/[id]. Вот такая вот цепочка получается… И вот с этой маской получается одна папка "$cache_prefix$contextKey", а не две папки "$cache_prefix/$contextKey", из-за чего и не выполнялось очищение кеша ресурсов (к слову не только ресурсов, но это не так важно, там причина такая же была).

В общем, если захотите настроить кастомные настройки кеширования, настоятельно рекомендую придерживаться этих правил.
6 комментариев
J
Jack_White 22 февраля 2015г в 16:21 #
Спасибо
Fi1osof1
Fi1osof 22 февраля 2015г в 16:28 #
Всегда пожалуйста
alroniks1
alroniks 23 февраля 2015г в 15:34 #
Кстати, насчет $config_options и кеширования через memcache, вот относительно старая статья Джейсона. modx.com/blog/2012/09/24/using-memcached-for-modx-caching/

У меня на одном интернет-магазине просто включение memcache без допнастроек увеличило производительность в 3 раза. Джейсон предлагает так же использовать кластер для больших проектов, чтобы разные сущности раскладывать по разным memcache инстансам. Это потом упрощает инвалидацию. Ну и важная причина — ограничение в 64M одного инстанса
Fi1osof1
Fi1osof 23 февраля 2015г в 16:15 #
Все верно, он и пишет:
Since the MODX cache configuration settings are part of what gets cached according to those settings, we have to inform MODX of these details before it loads the system settings. For this reason, there is a $config_options array in your MODX config file where you can specify settings which are applied before the system settings are loaded.

But before we do that, let's set up all of the partition configuration settings which will tell MODX which memcached instances will store which pieces of the cache.
То есть «мы и в системные настройки это забьем, и в главный конфиг-файл пропишем, чтобы MODX сразу учитывал эти настройки». Значит я все правильно сделал.

У меня на одном интернет-магазине просто включение memcache без допнастроек увеличило производительность в 3 раза.
Понятное дело, что производительность улучшится и без допнастроект, но все же с ними будет лучше.

P.S. За ссылку спасибо.
T
TITAN-UZ 24 марта 2015г в 16:26 #
Спасибо
Fi1osof1
Fi1osof 24 марта 2015г в 17:13 #
Пожалуйста!
Авторизуйтесь или зарегистрируйтесь (можно через соцсети ), чтобы оставлять комментарии.