Переделка кеширования у MODx

Всем привет.
Очень нужна ваша помощь и совет. Сразу приношу извинения за многобукв и нескладную «речь» — пишу на скорую руку.

Сейчас занимаюсь важным делом — пробую полностью переделать кеширование у MODx EVO. Возникла одна интересная идея, которой хочу поделиться.

Нашел интересную разработку https://github.com/PHPSocialNetwork/phpfastcache, которая позволяет использовать такие методы кеширования: apc, cookie, files, memcache, memcached, predis, redis, sqlite, ssdb, wincache, xcache на выбор или автоматический выбор. Хочу

1) Позволить им пользоваться для разработки сниппетов, модулей и т.д.
2) Переписать под нее систему кеширования MODx;

1. Кеширование для разработчиков



На основе phpfastcache сделал новое расширение, которое в момент инициализации ядра MODx становится доступным как
$modx->cache


Использование

Запись данных в кеш:
$modx->cache->set('ключ','кешируемые данные');

Считывание данных:
$modx->cache->get('ключ');


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

2. Система кеширования самого MODx


У стандартной системы кеширования есть как минимум два слабых места:

  1. Сгенерированный для страниц HTML пишется в файлы типа docid_1.pageCache.php, а количество сгенерированных кеш-файлов для страниц может достичь большого числа, что создает проблемы.
  2. Все настройки MODx посещается в файл siteCache.idx.php. Но если сайт большой (много документов, сниппетов, плагинов и т.д.) файл siteCache.idx.php разрастается и при инициализации MODx весь грузится в память, причем даже те данные, которые могут быть не нужны.


Как я предлагаю решить эти проблемы.

1) Писать сгенерированный HTML не в файлы, а кешировать их с помощью, напр., memcache, memcached, predis, redis, sqlite, ssdb, wincache, xcache, используя вышеприведенную разработку;

Я переписал ядро MODx (всего несколько строк кода) так, чтобы весь сгенерированный контент кешировался не в файлы типа docid_1.pageCache.php, а в моем случае memcache (можно выбрать любой другой способ). Результат — избавился от сгенерированных кеш-файлов, а производительность при этом совершенно не пострадала по сравнению с теперешним методом кеширования.

2) При генерации кеша загоняем все настройки не в siteCache.idx.php, в, напр., в memcache ( в виде ключ=значение) с помощью той же разработки
$modx->cache->get('ключ','кешируемые данные');

А потом загружаем эти настройки по мере необходимости.

Сейчас весь конфиг загружается с помощью $modx->getSettings(), причем весь кеш заливается в память и висит там все время, нужен он или нет. Зачем? Не проще ли было бы извлекать нужные данные вот так:
$modx->cache->get('ключ','кешируемые данные');

Например, мне нужно в сниппете получить информацию о языке системы управления. Это можно сделать так:
$modx->cache->get('config:manager_language');
. Будет извлечено только это значение.

Вот тут нужен ваш совет. Будет ли это эффективным решением? Конечно, придется тогда немного переписать и ядро MODx, и имеющиеся разработки. Или же каким-то образом обеспечить совместимость. Что вы думаете по этому поводу?

9 комментариев

avatar
Мне все же больше нравится подход Agel_Nash с использованием Twig, который решает обе проблемы. Ну или без Twig решает первую.
Вторая проблема мне вообще видится надуманной: Дима недавно хвастался миллионом документов с нынешним стандартным кэшем. А кэширование элементов и настроек вообще, по-моему, погоды не делает никакой (хотя и хотелось бы иметь возможность отключать в админке кэширование отдельных элементов).
avatar
Вполне согласен, что Женин вариант может быть эффективным. Вот только я о нем не знал. Сколько еще у каждого заначек в сундучке лежит… :)

Стандартный варинат кеширования действительно довольно хорошо справляется с большим количеством документов. У меня как минимум 25000 штук, работает все шустро. Но можно и лучше. Но работа с переделкой кеша куда более обширная, чем просто подключить какой-то драйвер кеширования. Там внутри ядра все завязано на том, что весь кеш с настройками, картой алиасов и т.д. хранится в памяти. Нужно и это учесть при доработке. Но если получится сделать, обязательно выложу для тестов.
avatar
У меня вопрос. Ваш метод можно реализовать исключительно плагинами? Просто насколько я вижу это либо хак, либо форк, а это либо поддерживать самостоятельно, либо согласовывать с сообществом (по сути с dmy3yy)
avatar
Плагинами не получится в полной мере это сделать, поэтому делается изменениями в ядре. С Димой мы обсуждали этот вопрос, он согласен, что если тесты будут положительными, можно подумать в внесении в официальную версию. Но вопрос об обратной совместимости стоит открытым, придется делать так, чтобы работало оба варианта кеширования и можно было обеспечить совместимость. Вот в этом и загвоздка…
avatar
Выпускается версия 1.2 и инструкция по обновлению (описания изменений АПИ). Незачем тащить за собой устаревший код.
avatar
чем просто подключить какой-то драйвер кеширования.
В любом случае лучше взять кешер Doctrine за основу. Меньше сущностей, если вдруг удастся доделать новый шаблон админки на базе Twig'a.

А вообще, план по развитию кешера я уже накидывал. Более того, у японцев это так или иначе реализовано. Вот только у меня руки не дошли перетянуть это в димину сборку…
avatar
Я думаю, что это очень актуальный вопрос. В любом случае с кешем нужно что-то решать. Если необходимо, соберем донат и будет делать.
avatar
Может сейчас у Вас получится найти время? ;)
avatar
А почему при любом POST, кэш обнуляется?!?!?! :(
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.