Работа с кэшерами в Revolution

Не все знают, что MODX Revolution умеет работать с разными системами кэширования, для чего применяет следующие классы:

xPDOFileCache — стандартный обработчик по умолчанию, хранит кэш в файлах.
cache.xPDOAPCCache — обработчик для расширения php-apc
cache.xPDOMemCached — обработчик для memcached. Есть заметка про него
cache.xPDOMemCache — обработчик для memcache.
cache.xPDOWinCache — обработчик для wincache. Это для windows хостингов, на IIS.

При большом желании, вы можете написать свой обработчик для любого кэшера. Нужно просто расширить класс xPDOCache и описать собственные методы: add, set, replace, delete, get, flush, по образу и подобию одного из этих классов.

Установка
Рассказывать буду про php-apc, ибо мне он нравится больше всего. Его легко установить и запустить. К тому же, он может войти в ядро php6. К тому же, про установку memcached я уже рассказывал.
Еще особенность: php-apc кэширует скомпилированный php код, а не только пользовательские данные. Это сильно экономит память и повышает отзывчивость.

Ставим на нашу обычную Ubuntu:

sudo apt-get install php-apc && sudo service php5-fpm restart

Активируем в настройках MODX:

Опции cache_prefix нет, по умолчанию, ее нужно создать. Это опция контекста, и если у вас на сайте их более одного — нужно писать в настройки контекстов. Также это необходимо, если вы хостите более одного сайта, пускай и с одним контекстом у каждого.

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

Использование
Вот тут самое сладкое — ничего. делать не нужно. Вы указали класс-обработчик для кэша, префикс для ключей и дальше MODX работает за нас, как обычно.

Волшебство!

Мы можем использовать специальные директивы глобально в apc.ini. Обратите особое внимание на apc.shm_size — это объем памяти для apc.
Некоторые параметры, типа apc.cache_by_default, можно использовать в конфиге определенного сайта php5-fpm.

Еще в комплекте идет полезный скрипт — он находится в /usr/share/doc/php-apc/apc.php.gz. Можете скопировать его в секретную директорию на сайте и разглядывать статистику. Если в файле задать пароль для авторизованного юзера, то можно видеть более подробную информацию и чистить кэш.

Результаты
Сразу после установки php-apc все php скрипты начинают работать быстрее. Но лично я столкнулся с разными глюками при работе с сессией в miniShop — она кэшировались. Поэтому долгое время не пользовался этим прекрасным кэшером, во избежание.

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

Сейчас на modx-minishop.ru php-apc включен, и никаких проблем с корзиной нет.
Поэтому, если на сервере установлен php-apc — или отключайте его у сайта (через .htaccess, конфиг php), или включите правильный обработчик.

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

На MODX Cloud, насколько я знаю, php-apc установлен по умолчанию.

Обновлено 17.12.2014

Важное уточнение по поводу инициализации настроек кэширования — в комментарии ниже.

Василий Наумкин

15 октября 2012, 16:53

23 128

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

Valentin Rasulov

15 октября 2012, 21:18

Во — а про cache_prefix не знал, спасибо.
Наслышенна тема, но я с ней сталкнулся только на локалке. у меня стоит локальный веб сервер MAMP и в нём по дефолу 3 вида кэша (XCache, eAccelerator и Alternative PHP Cache (APC)) и поигравшись сними я прозрел от APC. После чего дал идею тебе попробовать в живую (хитёр я!!!!, нет просто у меня и так кэшами был апач загручен, а сейчас перенёс всё на nginx и уже после того, как ты подтвердил — всё класс!, установил и себе).

Василий Наумкин

15 октября 2012, 21:34

И каков он? У меня было 10,5, стало 7.

Может, php-apc уже был установлен?

Denys Butenko

15 октября 2012, 21:34

Активировал, но что-то объем используемой памяти остался прежним) Проверяется вашим сниппетом.

Василий Наумкин

15 октября 2012, 21:36

И каков он? У меня было 10,5, стало 7.

Может, php-apc уже был установлен?

Denys Butenko

15 октября 2012, 21:50

Нет, проблема оказалась в том, что php-apc с первого раза не удачно установился в /etc/php5/apache2/conf.d не появился apc.ini в котором указано extension=apc.so. Нигде не мог найти этот файл. Сделал apt-get purge php-apc, apt-get install php-apc — появился apc.ini. А обнаружил, в журнале ошибок. Вдруг, кому на будущее пригодится.

Итог: Было ~12Мб на главной странице, сейчас 5,34Мб

Valentin Rasulov

15 октября 2012, 22:05

проверить можно просто, установлен или нет. Удаляем папку cache и открываем любой ресурс в фронте, если в кэше нету ресурса — значит всё Окей.

Иван Брежнев

15 октября 2012, 22:07

Т.е. все упирается теперь в объем оперативной памяти?
И все запросы и блоки отрендеренные писать также в оперативку?

Василий Наумкин

15 октября 2012, 22:10

Да. За счет этого будет просто молниеносный кэш.

По htop разницы в потреблении памяти не заметил. Объем выделенной памяти можно настроить в apc.ini. По умолчанию — 32M.

Denys Butenko

15 октября 2012, 22:11

У меня php5-fpm начал набирать в весе. Раньше больше 5-7% не кушал, сейчас уже за 10,5% перевалил)

Valentin Rasulov

15 октября 2012, 22:15

баланс по любому должен быть, или как без этого. Мы хотим и быстро и при этом не расходуя ничего? Если в файлах кэш — растёт объём файла, всё вроде логично.

Иван Брежнев

15 октября 2012, 22:18

Вот все таки мне кажется нужно писать симбиоз APC и FileCache. То что редко используется кидаем в файловый кэш, все остальное в RAM

Василий Наумкин

15 октября 2012, 22:22

Вань, ну ты хоть попользуйся маленько то. Поди не дураки делали, соображают кой-чего?

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

Иван Брежнев

15 октября 2012, 22:24

Я понял, нужно просто пробовать. Лучше раз пощупать чем 10 раз спросить.

Для меня самообучение дает больший эффект чем поспрашивать))) Это просто для общей информации спросил

Василий Наумкин

15 октября 2012, 22:26

Зацени — bezumkin.ru/apc.php

Иван Брежнев

15 октября 2012, 22:28

Круто. Там и видно какие файлы он закэшировал)

Denys Butenko

15 октября 2012, 22:23

Я не спорю) Логично) Сейчас натравил loadimpact.com, чуть позже результат скину)

Иван Брежнев

15 октября 2012, 21:47

А стандартные средства кэширование так же будут работать?
Имею ввиду вот такие

Пишем в кэш /core/cache/my_cache_dir
$modx->cacheManager->set($id, $collection, 86400, array(xPDO::OPT_CACHE_KEY => 'my_cache_dir'))

Получаем данные из кэша /core/cache/my_cache_dir
$collection = $modx->cacheManager->get($id, array(xPDO::OPT_CACHE_KEY => 'my_cache_dir'))

Василий Наумкин

15 октября 2012, 21:49

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

Методы set, get и прочие — расширены. Смотри исходники по ссылке в начале.

Иван Брежнев

15 октября 2012, 21:52

Смотрю, не будут работать(

Иван Брежнев

15 октября 2012, 21:54

Теперь чтобы писать в локальный файловый кэш нужно использовать writeFile

Василий Наумкин

15 октября 2012, 21:56

Ты не понял.

Есть разные обработчики кэша. Если ты включаешь cache.xPDOAPCCache — то все методы работают с ним. Хочешь файлов — гоняй стандартный xPDOFileCache.

Хочешь и то и то — пиши свой обработчик или при кэшировании юзай функции нужного кэшера.

Короче, напрягай фантазию — возможно все.

Иван Брежнев

15 октября 2012, 21:57

Вот, я так и подумал что нужно свой класс чтобы он и с APC и с файловым кэшем работал

Иван Брежнев

15 октября 2012, 21:58

Методы set и get будут писать уже не в /core/cache а в APC

Василий Наумкин

15 октября 2012, 22:01

В этом и смысл — они пишут в оперативную память.

Методы writeFile написаны для xPDOFileCache, и их никто не мешает использовать. Только зачем?

Система и так умно хранит в файлах настрjйки менеджера, системы и еще по мелочи.

В общем, я заметку написал — а ты развлекайся =)

Евгений Дурягин

16 октября 2012, 00:45

Свой класс не обязательно. В MODX система кэширования гораздо гибче. Там выбор класса для кэширования идет что-то типа по ключу, точно не помню, экспериментировал год назад наверное. Если ключ не задан, то используется класс по умолчанию. Например если указать resource_cache_handler = cache.xPDOMemCache, а cache_handler=cache.xPDOAPCCache, то он ресурсы будет кэшировать в memcached, а все остальное в APC. Можно в сниппетах использовать свои ключи и кэшировать куда нужно.

Вот статья для ознакомления modx.com/blog/2012/09/24/using-memcached-for-modx-caching/ Там, как видно, Jason Coward кэширует разные элементы в разные истансы memcached, точно также можно и разные классы прописать.

Иван Брежнев

16 октября 2012, 00:50

Классно)

Евгений Дурягин

16 октября 2012, 00:51

Кстати, помоему этого и достаточно
$modx->cacheManager->set($id, $collection, 86400, array(xPDO::OPT_CACHE_KEY => 'my_cache_dir'));

Если ты создашь настройку my_cache_dir_cache_handler=xPDOFileCache
То он будет кэшировать в файлах, остальное куда указывает cache_handler

Иван Брежнев

16 октября 2012, 01:06

И так для каждой директории?

Евгений Дурягин

16 октября 2012, 10:18

Ну можно еще и так:
$modx->cacheManager->set('key123', $str, 3600, array(
xPDO::OPT_CACHE_KEY => 'blablabla',
xPDO::OPE_CACHE_HANDLER => 'xPDOFileCache')
);
Сохранит в файлах

$modx->cacheManager->set('key123', $str, 3600, array(
xPDO::OPT_CACHE_KEY => 'blablabla',
xPDO::OPE_CACHE_HANDLER => 'cache.xPDOMemCache',
'blablabla_memcached_server' => 'localhost:11211'
)
);
Сохранит в memcached

Хотя это все насколько я помню, нужно все перепроверять.

Евгений Дурягин

16 октября 2012, 10:18

Опечатка, должно быть xPDO::OPT_CACHE_HANDLER

Иван Брежнев

16 октября 2012, 14:43

Либо я еще вот такой вариант думал

$modx->cacheManager->set('key123', $str, 3600, array(
xPDO::OPT_CACHE_KEY => 'my_cache_key',
xPDO::OPT_CACHE_PATH => 'my/cache/path'
)
);

И в настройках cache_handler указать my_cache_key_cache_handler = xPDOFileCache

Евгений Дурягин

16 октября 2012, 14:58

Только при беглом просмотре исходников PDO::OPT_CACHE_PATH должен равнятся абсолютному пути.

Евгений Дурягин

16 октября 2012, 15:01

Лучше использовать xPDO::OPT_CACHE_PREFIX

Иван Брежнев

16 октября 2012, 15:28

Нужно пробовать.

~~Fi1osof~~

17 декабря 2014, 13:03

Не дочитал я)) По сути тоже самое ниже написал.

Василий Наумкин

15 октября 2012, 21:54

Ты чем смотришь то?

class xPDOAPCCache extends xPDOCache

Внутри все методы cacheManager, переопределенные для работы с APC.
https://github.com/modxcms/revolution/blob/develop/core/xpdo/cache/xpdoapccache.class.php

Как это оно работать не будет, когда оно для того и придумано?!

Иван Брежнев

15 октября 2012, 22:00

Я как раз этот класс и поматрел и понял что он описанные мной методы переопределяет

Василий Наумкин

15 октября 2012, 22:02

Именно в этом и смысл включения другого ОБРАБОТЧИКА КЭША.

Иван Брежнев

15 октября 2012, 22:26

Изучаю PHPStorm, глянь чего он умеет, круто
i45.fastpic.ru/big/2012/1015/cf/85d1d5879647384e1047a49e54d709cf.png

Иван Брежнев

15 октября 2012, 22:04

Кстати не в тему вопрос, но хотел спросить почему ты выбрал PHP после того как начал изучать питон. Мне питон до сих пор симпатизирует. Пытаюсь Джанго потихоньку изучать.
Нравится мне синтаксис Питона.

Из PHP фреймов щас щупаю FuelPHP

Василий Наумкин

15 октября 2012, 22:07

Так я не после, я во время.

Сначала глубоко поучил PHP, потом стало скучно — полез читать про другое. Но значительных прелестей не обнаружил и пока забросил.

Как встречу что-то, чего не могу (но должен) сделать на PHP — вернусь к обучению.

Пока все силы предпочитаю тратить на работу с PHP в целом, и MODX Revolution, в частности — так каждый день открытия.

Иван Брежнев

15 октября 2012, 22:08

Я понял.

Иван Брежнев

15 октября 2012, 22:09

Кстати может написать статью как правильно подружить phpstorm и modx. Многим начинающим будет интересно.

Василий Наумкин

15 октября 2012, 22:12

Напишу, но только после того, как сам разберусь до «уверенного юзера».

Иван Брежнев

15 октября 2012, 22:16

Я вот как раз тоже разбираюсь. Можно спросить у Valikrasa он уже давно им пользуется.

Valentin Rasulov

15 октября 2012, 22:20

ага на несколько недель раньше :)
P.S. А кто такой Valikras?

Иван Брежнев

15 октября 2012, 22:22

Точно)) У Валика можно спросить.

~~Fi1osof~~

17 декабря 2014, 13:01

Ваня, привет!
Если тебе нужен именно файловый кеш-манагер (мне такое часто надо, не смотря на то, что используется мем-кешер, просто для того, чтобы что-то в файлы записывать и не заморачиваться с наличием директорий:)), то ты можешь несколько вариантов использовать.
Самый простой — это просто через $modx->getService() или new $className() (это ты и сам знаешь), но есть более правильный путь — юзать $modx->cacheManager->getProvider(). Просто MODX умеет одновременно работать с несколькими провайдерами. При этом есть вот такой вариант:

$manager = $modx->cacheManager;
$provider = $manager->getCacheProvider('file_cacher_key', [
    "file_cacher_key_cache_handler" => "xPDOFileCache",
]); 

$param = 'some value';
$key = "param_key";
$provider->set($key, $param);

Здесь ты работаешь с объектом конкретного кеш-провайдера. Обрати внимание в передаваемых параметрах: ключ провайдера является префиксом для параметра в массиве. file_cacher_key file_cacher_key_cache_handler. Ключ можно любой указывать, но правило соблюдать надо (только обязательно указывать и не default, иначе будет возвращен текущий кеш-провайдер, так как default — это его ключ в массиве провайдеров кеш-манагера).

Но в данном случае не совсем удобно то, что если будет желание еще в каком-то месте с ним поработать, то надо будет опять юзать getCacheProvider(). Вот другой вариант:

$manager = $modx->cacheManager;
$manager->getCacheProvider('file_cacher_key', [
    "file_cacher_key_cache_handler" => "xPDOFileCache",
]); 

$param = 'some value';
$key = "param_key";
$manager->set($key, $param, null, array(
    xPDO::OPT_CACHE_KEY => "file_cacher_key",
));

Здесь мы уже указываем ключ в методе set() самого кеш-манагера (само собой и в get() можем и т.п.). То есть метод $manager->getCacheProvider() получается своего рода регистратор кеш-провайдера, который можно один раз вызвать где-нибудь в плагине на OnHandlerRequest или типа того, а потом юзать стандарные set() И get(), просто указывая ключ файлового кеш-провайдера (или какой нужен).

Denys Butenko

15 октября 2012, 22:29

До https://loadimpact.com/load-test/gadgets.lg.ua-32641fb4d2c85ed3d465c7cc1a5293a7
После loadimpact.com/load-test/gadgets.lg.ua-68d6d7b1da2561b278d46aa9999e47aa

Valentin Rasulov

15 октября 2012, 22:33

если быть слепому — то почти без разницы!

Василий Наумкин

15 октября 2012, 22:35

Ну как тут не поржать над дебилом-с-того-форума.

Valentin Rasulov

15 октября 2012, 22:33

в семь с половиной раз

Denys Butenko

15 октября 2012, 22:35

Ну, предыдущий тест я делал пару месяцев назад. Но тем не менее, был еще один, там около ~9 секунд среднее. Вообщем прирост ощутимый, учитывая, что сервера в России, а наплыв из США.

Иван Брежнев

15 октября 2012, 22:55

gadgets.lg.ua/catalog/tablets/chuwi-v99/
Загрузка страницы: 8,0703 s

Память: 7,14 Мб

8 сек это очень много

Denys Butenko

16 октября 2012, 22:18

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

Иван Брежнев

16 октября 2012, 22:23

Все равно это очень много. У меня когда рендер достигает 2 сек. я ужу чуть седым не становлюсь =) т.е. начинаю копаться в коде и оптимизировать все что можно.

Denys Butenko

17 октября 2012, 16:24

на странице происходит вызов:
[[!msGetGoodsPlaceholders]], [[msGetGallery]], [[!LikeDislike]], [[getRelated]], [[TvList]], [[getViewed]] и еще несколько чанков. Проблему нашел: msGetGallery увеличивает загрузку на 4сек, getViewed еще где-то на 1.5с и getRelated 1.5с. Выключив всё это, результат 1сек без кэша.

Иван Брежнев

17 октября 2012, 16:28

уже лучше, я переписал msGetGallery чтобы он не объекты извлекал а массивы и базы. Так быстрее

Denys Butenko

17 октября 2012, 16:47

Да, msGetGallery однозначно грузит, там где больше 7 фотографий загрузка страницы > 11 сек. Поделитесь своим вариантом msGetGallery

Иван Брежнев

17 октября 2012, 18:40

Отправил на почту свой вариант, и еще я не использую сниппет phpthumbof, а написал свой маленький который работает с Imagick, он при аплоаде изменяет сразу фотку на нужные размеры, а если вы заливали через фтп, то в вызове сниппета просто указываете размеры изображений, &size=`150x150`, и все, он создает папку thumbs там где лежит фотка и туда записывает уменьшенное изображение

Denys Butenko

17 октября 2012, 20:21

А на какую почту?)

Denys Butenko

15 октября 2012, 22:39

Вот этот более точнее описывает картинку
https://loadimpact.com/load-test/gadgets.lg.ua-457ef3ef3a04cf92bdc21062b61c4f4c

Иван Брежнев

15 октября 2012, 22:41

Ты с Луганска или из области?

Denys Butenko

15 октября 2012, 22:46

Луганск

Иван Брежнев

15 октября 2012, 22:47

И я

Valentin Rasulov

15 октября 2012, 22:47

Иван — это не сайт знакомств… :)

Иван Брежнев

15 октября 2012, 22:48

ЫЫЫЫ, точно))

Иван Брежнев

15 октября 2012, 22:52

Странно, почему время генерации такое высокое, что у тебя за сниппеты на главной?

Denys Butenko

15 октября 2012, 23:50

Из кеша она отдается за 0.25с.

Денис

15 октября 2012, 22:41

А в основном у любого хостинга php-apc имеется?

Иван Брежнев

15 октября 2012, 22:41

Нет.

СикретНаме

15 октября 2012, 23:08

Как вовремя заметочка появилась! Не подскажете, какой способ замера времени генерации страниц самый простой и надёжный для MODX Revo (если это имеет значение, кнш)? Так, что бы в футере, как у Вас на атлетик-сити было видно.

Василий Наумкин

15 октября 2012, 23:17

Плейсхолдер [^t^].

СикретНаме

15 октября 2012, 23:20

Это-то да, а он надёжен? Просто у Вас на атлетик-сити скрипт, походу, микротаймовый, вот мне и стало любопытно-закрались сомнения… Почему выбор Ваш таков и с чем связано.

Иван Брежнев

15 октября 2012, 23:21

Так микротаймовый и нужен, у вас же страница не по пол часа генерируется

Василий Наумкин

16 октября 2012, 05:28

Это он и есть.

После обработки страницы парсер MODX пишет затраченный микротайм в плейсхолдер [^t^] — он и выводится у меня в футере.

СикретНаме

16 октября 2012, 11:19

По поводу плейсхолдера я так и подозревал, а то, что «render time:» — это обычный текст прописанный перед плейсхолдером не подумал, и решил, что там что-то неведомое, вот я мамонт… Спасибо за науку, постараюсь быть внимательнее к таким вещам!

Антон Слободчук

16 октября 2012, 00:00

Работает, однако в логах у меня теперь «сыпит» ошибками:
[Mon Oct 15 23:55:35 2012] [error] [client 95.28.49.19] PHP Catchable fatal error: Argument 1 passed to xPDOObject::load() must be an instance of xPDO, instance of modX given in /var/www/vhosts/site.ru/httpdocs/core/xpdo/om/xpdoobject.class.php on line 404, referer: www.site.ru/ap/?a=30&id=1
Также при обновлении кэша через админку останавливается на «Очистка основного кэша: mSearch».

Антон Слободчук

16 октября 2012, 00:10

Упс… Пардон, у меня и со стандартным xPDOFileCache такие ошибки в логах и при очистки кэша — то же самое.

Александр Наумов

16 октября 2012, 15:19

Спасибо, очень полезная статья!

Григорий Розенбаум

16 октября 2012, 17:05

Только как три дня разобрался с проблемой из за APC… Делаю сайт на рево, инет-магазин (используется шопкипер, мини-шоп пока не тестировал), домашний образ убунты — все окей, а на сервере не работает (петерхост) корзина- или не обновляется или во время добавления ошибка. После нескольких дней мучений наконец-то вставил в htaccess apc.cache_by_default off и все заработало!
А может быть просто надо было изменить класс в натройках Modx? Или это все таки косяк разработчиков? Если да — надо на форме попросить, чтобы они доработали скрипт для работы с php-apc.

Василий Наумкин

16 октября 2012, 17:23

При файловом классе и включенном apc сессия кэшируется и некорректно работает. Это не глюк.

Либо класс менять, либо apc отключать — одно из двух.

Denys Butenko

16 октября 2012, 22:20

Подскажите, как создать кэш всех страниц не заходя на них после очистки?)

Иван Брежнев

16 октября 2012, 22:26

Я думаю нужно написать плугин на событие OnSiteRefresh который будет ходить по всем опубликованным ресурсам. Но это накладно как мне кажется. И если у вас рендер одной страницы достигает 8 сек. ты можно легко упереться в time limit

Виталий Вайти

25 октября 2012, 02:08

Любопытства ради проделал данную операцию, но вот беда:
захожу в настройки MODX, выбираю «Статус сайта»=нет (ID страницы когда сайт недоступен установлен).
Делаю — очистить кэш, перехожу на главную странице (не авторизованным пользователем) — сайт доступен. Очищаю вручную (удаляю все из директории: /core/cache/), захожу на главную страницу — работает.

Ключ для кэша создан, Класс-обработчик системы кэширования: cache.xPDOAPCCache.
Посмотрел папку /core/cache/system_setting/
присутствуют 2 файла:
config.cache.php & [cache_prefix]_config.cache.php (cache_prefix=site19_).

Данные из файлов отличаются:
в config.cache.php 'site_status' => '1'
в [cache_prefix]_config.cache.php 'site_status' => '0'

В настройках системы Статус сайта=Нет.
Кнопку очистить кэш нажимал не один раз, но это не помогает.

Это у всех так или только у меня?

Valentin Rasulov

25 октября 2012, 05:54

-> перехожу на главную странице (не авторизованным пользователем) — сайт доступен.
Вы с другого браузера заходите? вернее чтобы сессия не попала ваша если вы находитесь в админке.

Виталий Вайти

25 октября 2012, 05:54

Да с другого. Настройки меняю в Chrome, смотрю в Firefox.

Valentin Rasulov

25 октября 2012, 06:31

я не внимательно прочитал ваш коммент выше, я понял, что после очистки папки cache у вас всё работает правильно?
Я не проверял с статусом сайта, но после изменения системных настроек, языковых файлов и.т.д., я всегда удаляю папку cache (к стате, самый быстрый способ очистить содержимое папки — в дереве файловой системы, просто удаляем папку core/cache она сразу автоматом создаётся с обновленными системными настройками.)

Виталий Вайти

25 октября 2012, 06:40

Угу, после удаление файлов из папки core/cache все нормально.
Вероятно это из-за того что выбран тип cache.xPDOAPCCache.

Еще я пытался «играться с настройками», заходил в контексты и создавал там параметр cache_prefix с (web & mrg — сразу и по отдельности) одинаковыми параметрами, в результате настройки сохраняются и без удаления core/cache, но опять же есть проблема, которая не позволяет это использовать, а именно:
«Иначе, все данные будут кэшироваться без уникального префикса, и на одном сайте вылезет кэш от другого. Будет не круто, уверяю.»

Т.е. у меня на 3 сайтах был 1 и тот же сайт.

На modx.com попадалась статья на англ. языке, из которой, как я понял опять же, эта проблема связана именно с типом кэша.

Василий Наумкин

25 октября 2012, 08:54

Да, есть такой баг, но.

Если указать у web и mgr один префикс, и он будет уникальным для этого сайта — то должно работать.

А у другого сайта другие префиксы для mgr и web, но между собой одинаковые.

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

Виталий Вайти

25 октября 2012, 14:16

«Если указать у web и mgr один префикс, и он будет уникальным для этого сайта — то должно работать.

А у другого сайта другие префиксы для mgr и web, но между собой одинаковые.»

Именно так и пытался сделать, сначала создается впечатление что все работает, но потом:

«Иначе, все данные будут кэшироваться без уникального префикса, и на одном сайте вылезет кэш от другого. Будет не круто, уверяю.»

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

Василий Наумкин

25 октября 2012, 14:30

У меня на сервере сейчас штук 5 сайтов с включенным php-apc — все ок, проблем нет.

Префикс пишу в системные настройки, не в контекст.
Когда заморочки с кэшем — удаляю /core/cache

Дальше разбираться пока времени нет.

Виталий Вайти

25 октября 2012, 15:11

Василий, могу ли я вас попросить об одолжении, когда будет возможность, проверить работу 2-х сайтов у которых префиксы для mgr и web указаны и обновляются ли настройки, к примеру, Статус сайта (да/нет) и Название сайта, без удаления папки /core/cache?

Sadykh Sadykhov

04 ноября 2012, 12:32

Спасибо за заметку!

Была проблема — кэш из админки не чистился при редактировании шаблонов/чанков, только ручное удаление. С правами всё нормально было, узнал что стоит нативный php-apc. Поставил cache.xPDOAPCCache и его префиск — всё стало отлично работать. Спасибо большое!

Евгений Борисов

06 ноября 2012, 12:23

PHP-APC не совместим с ZendOptimizer

СикретНаме

13 февраля 2013, 07:02

Отличная штука!!!

Виталий Киреев

03 марта 2013, 12:56

А почему может быть такое, что больше 59М в apc.ini память не устанавливается? При рестарте php5-fpm выдает [fail]. htop показывает около 150 свободного при этом.

Мордынский Николай

04 апреля 2013, 15:53

Интересный момент в настройках постраничной навигации с помощью getPage.
Сам сниппет и его плейсхолдер требуют не кэшированного вызова. Однако в параметрах есть настройки для кэширования. Попробовал их включить и вызвать getPage@paramName (paramName — пользователькие настройки).

Время генерации страницы на каталоге MS 1 c выводом 25 наименований упало с 0.7 до 0.18

СикретНаме

16 апреля 2013, 16:25

Какие-то странности творятся. После апгрейда скорость жутко упала, в коде сайта ничего не менял. С чего бы такие чудеса могли взяться, не в курсе? Правда прописывал 128М, тогда как до апгрейда этой строки не ставил вообще (может в этом дело?).

Сергей Шлоков

27 апреля 2013, 19:06

А как подружить Hybrdauth и php-apc? Как только этот кэшер влючаю, авторизация отваливается.

Василий Наумкин

27 апреля 2013, 19:11

Не знаю, у меня работает нормально.

В любом случае, это вина лежит на взаимодействии MODX с php-apc, ибо сам HA ничего не кэширует, а просто кладёт настройки с сессию обычным способом.

Сергей Шлоков

27 апреля 2013, 22:43

Жаль. php-apc даже на глаз работает шустрее. Странно, у тебя работает, а у меня и еще некоторых не хочет — redirect_uri_mismatch мать его.

Евгений Дурягин

28 апреля 2013, 14:33

Это вроде из-за того что MODX по умолчанию использует пользовательский обработчик для сессии и при завершении PHP он разрушается раньше, чем успевают записаться последние изменения в сессии, которые APC видимо кэширует.
Попробуйте создать плагин на событие OnInitCulture

<?php
register_shutdown_function('session_write_close');

OnInitCulture конечно не совсем подходящее событие, но оно просто единственное, которое выполняется всегда, даже если MODX в API режиме. По крайней мере на MODXCloud это помогло.

Сергей Шлоков

28 апреля 2013, 10:06

После неудачной попытки с php-apc вернулся на стандартный кэшер —
1. Раскомментировал строку

ini_set('apc.cache_by_default', 'Off'); // Отключение кэширования php-apc

2. Вернул стандартный класс обработчика в настройках xPDOFileCache.
3. Удалил префикс.
4. Почистил все кеши на всякий.
Но в итоге все равно redirect_uri_mismatch. А php-apc не отключается судя по php-info:

Василий, без твоей помощи не обойтись.

Василий Наумкин

28 апреля 2013, 13:21

Попробуй еще удалить директорию /core/cache/.

В phpinfo() он и не должен отключаться, если только вообще модуль не загружать — но так не надо, будет памяти больше уходить.

Сергей Шлоков

28 апреля 2013, 15:13

Не помогло. Подтверждение мудрости «Лучшее — враг хорошего». Работало все. Нет, надо было улучшить. Может loginza прикрутить вместо ha?

Василий Наумкин

28 апреля 2013, 16:11

Вот это вот у тебя где прописано?

ini_set('apc.cache_by_default', 'Off');

Пропиши в /index.php, если оно не там. Если и тогда не поможет — пришли данные от сайта на bezumkin@yandex.ru — погляжу.

Сергей Шлоков

28 апреля 2013, 17:08

Спасибо за помощь. Так не хотелось от hybrid отказываться. Теперь и не придется. Хорошо Гугл хоть пишет подробности ошибок. От Яндекса и Фейсбука кроме ошибки 400 ничего нет.
Сейчас гоняю на cache.xPDOMemCached. Пока гут. Еще раз спасибо.

Сергей Шлоков

28 апреля 2013, 16:17

Ура, заработало! В .htaccess разкомментировал переадресацию с www.site.ru на site.ru (закомментировал позавчера для корректной индексации Яндексом зеркал по рекомендации службы поддержки Яндекса). Странно, я во всех сервисах указываю без www. Почему Яндекс, Гугле, Фейсбук добавляют в адрес www не понятно.

Сергей Шлоков

27 апреля 2013, 22:42

См. коммент выше

Пётр Молчанов

13 мая 2013, 12:28

Поставил-таки php-apc, включил нужный кешер в настройках. Всё стало работать шустрее, но существует эта долбанная проблема с сессиями:
1. hybrid работает тока при ini_set('apc.cache_by_default', 0); в индекс файле. это разве не отключает кешер для всего сайта?
2. после регистрации пользователь автоматически не залогинивается и к тому же пароль на почту приходит в закодированном виде.
Не хотелось бы отказываться от этого кешера, т.к. работает шустро и развитие в любом случае будет. Василий, могли бы вы чем-нибудь помочь, подсказать где копнуть? Отключал кеширование БД и сессий (с удалением /core/cache/), но не помогает…

Василий Наумкин

13 мая 2013, 13:33

В системный настройках можно отключить хранение сессий в БД, это должно помочь

Пётр Молчанов

13 мая 2013, 14:36

Не нашел такого… Есть «Включить кэширование базы данных (cache_db)» и «Включить кэширование сессий, обрабатываемых базой данных (cache_db_session)», писал выше что обе эти настройки выключал, чистил /core/cache/ но эффекта не было(((

Василий Наумкин

13 мая 2013, 15:16

rtfm.modx.com/display/revolution20/session_handler_class

Пётр Молчанов

13 мая 2013, 15:37

Спс. Но че-то не помогло, все также не авторизует сразу после регистрации, хотя в остальном проблем нет. Что ж за напасть… видимо, придется отключать apc

Пётр Молчанов

13 мая 2013, 15:49

А может дело и не в apc… Включил дебаг в конфиге и вот какая ошибка выскакивает при регистрации: No foreign key definition for parentClass: modUser using relation alias: Services. С чем это может быть связано?

Пётр Молчанов

13 мая 2013, 16:11

Эта ошибка создается моим плагином, но и при его отключении пользователя не авторизует после регистрации… Аще магия какая-то

Пётр Молчанов

13 мая 2013, 16:37

При чем авторизует без проблем… Уже и модуль Login переустанавливал — не помогло

Пётр Молчанов

13 мая 2013, 17:21

Кажись разобрался))) Как обычно — некая кривизна рук. Тьфу-тьфу, пока не буду ничего трогать, раз работает)))

Василий Наумкин

13 мая 2013, 19:01

Молодец!

Пётр Молчанов

13 мая 2013, 17:22

А php-apc действительно крут. Благодаря нему уменьшил оперативу с 2гб до 1.5гб и серв прекрасно справляется, своп теперь ему только снится))))

Пётр Молчанов

07 августа 2013, 11:45

У мя на CentOs 6.4 x64 ставится apcu и modx отказывается на неё работать. Кто-нить уже сталкивался с таким?

Пётр Молчанов

08 августа 2013, 12:14

Удалось запустить на этом apcu, но не работает админка, пишет:

[08-Aug-2013 12:10:40] WARNING: [pool www] child 7012 said into stderr: "NOTICE: PHP message: PHP Warning:  array_merge(): Argument #2 is not an array in /home/***/core/model/modx/modx.class.php on line 2231"
[08-Aug-2013 12:10:40] WARNING: [pool www] child 7012 said into stderr: "NOTICE: PHP message: PHP Fatal error:  Class 'modUser_' not found in /home/***/core/xpdo/xpdo.class.php on line 763"

И не отображаются некоторые элементы на самом сайте, которые не кешируются (ну не должны которые) вроде как

Володя

14 августа 2013, 17:08

Василий привет, а проблема с apc кешером в работе minishop2 и tickets осталась? Ну то есть требуется его отключать как и раньше? или нет…

Василий Наумкин

14 августа 2013, 19:47

Вроде бы (вроде бы) вылечено.

Проверь, отпишись.

Антон Соловьёв

01 октября 2013, 18:48

Скажите, при авторизации через HybridAuth возникала ошибка You cannot access this page directly.
я быстро нашёл в поиске, что для этого нужно в index.php добавить ini_set('apc.cache_by_default', 'Off'); // Отключение кэширования php-apc
вставил, глюк пропал.
но ведь не может же быть, чтоб HybridAuth не мог в принципе работать с php-apc.
или мы добавив в индекс отключение apc.cache_by_default вырубаем его не для всей cms и по-этому можно юзать этот тип кеширования?

Aртур Чикин

20 ноября 2013, 09:52

Тоже интересует данный вопрос. Google не сильно помогает.

Николай

12 ноября 2013, 11:30

Проработал APC часов 10 и затем увел сервер в аут с ошибкой
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626+lfs/apc.so' — /usr/lib/php5/20090626+lfs/apc.so: cannot open shared object file: No such file or directory in Unknown on line 0

Володя

16 декабря 2013, 14:57

Ребята привет. Подскажите как APC кешер отключить на сервере под фряхой?
ни ini_set('apc.cache_by_default', 'Off') в index.php
ни php_flag apc.cache_by_default off в .htaccess
ничего не помогает. Кеширует все наглухо…
если перевести modx с файлового кешера на apc — тоже результатов нет…
что еще можно попробовать?

Василий Наумкин

16 декабря 2013, 15:10

Наверное, у тебя там не php-apc работает. Смотри в phpinfo(), там может быть и xcache, и memcache и opcache и еще что-нибудь.

Ну а если там все-таки php-apc, значит настройки сервера не дают сменить значение настроек скрипту — такое тоже запросто бывает.

Володя

16 декабря 2013, 15:55

Из кешеров только APC увидел — joxi.ru/wOmuUv3JTJDIMB-xAvs
Насчет opcache есть вот такие упоминания и все — joxi.ru/lOmuUv3JTJB-L7TmHuA
ОНО?

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

Василий Наумкин

16 декабря 2013, 16:00

1. Удаляй директорию /core/cache — так вернее.

2. Покажи-ка скриншот phpinfo() с параметром apc.cache_by_default?

Володя

16 декабря 2013, 16:09

1. так и делаю)
2. joxi.ru/dO2uUhjKTJDzbqUswjo

Василий Наумкин

16 декабря 2013, 17:28

Ну тогда я хз.

Пиши в поддержку, пусть расскажут, что там еще накрутили.

Пётр Молчанов

29 января 2014, 12:30

А что по поводу OpCache в php 5.5? Как будет работать modx с ним?

Aртур Чикин

29 января 2014, 13:37

Так словно его и не существует.

Пётр Молчанов

03 февраля 2014, 16:12

Забавно… Поставил стандартный файловый кеш в настройках (был apc), удалил apc, установил opcache. В итоге стало: total time: 0,0808 s (было 0,14 s)

Василий Наумкин

03 февраля 2014, 16:22

Ну, не зря же opcache заменяет все остальные в php 5.5.

Рустам С

11 ноября 2014, 19:46

Поставил apc-php
префикс добавил, кэш вроде создается
но при очистки кэша из админки выдает
prntscr.com/55bvcp

Консоль запущена...
xPDOAPCCache[auto_publish]: Error creating APC cache provider; xPDOAPCCache requires the APC extension for PHP, version 2.0.0 or later.
xPDOAPCCache[media_sources]: Error creating APC cache provider; xPDOAPCCache requires the APC extension for PHP, version 2.0.0 or later.
xPDOAPCCache[scripts]: Error creating APC cache provider; xPDOAPCCache requires the APC extension for PHP, version 2.0.0 or later.
xPDOAPCCache[default]: Error creating APC cache provider; xPDOAPCCache requires the APC extension for PHP, version 2.0.0 or later.
xPDOAPCCache[resource]: Error creating APC cache provider; xPDOAPCCache requires the APC extension for PHP, version 2.0.0 or later.
xPDOAPCCache[menu]: Error creating APC cache provider; xPDOAPCCache requires the APC extension for PHP, version 2.0.0 or later.

что это?

Пётр Молчанов

12 ноября 2014, 13:53

Очевидно же, что необходима более новая версия библиотечка APC для php. Какая версия php, какая ОС?

Рустам С

12 ноября 2014, 14:37

ставил из панели ispmanager, там да вроде старая… но как я понял проект не развивается? альтернатива APC сейчас что? в пхп5.5 вроде есть стандартный?

Пётр Молчанов

12 ноября 2014, 14:49

OPCache в 5.5 есть по-умолчанию, чтобы его использовать ставь файловый кеш (который по-умолчанию). Попробуй установить apcu, это дальнейшее развитие apc

Рустам С

12 ноября 2014, 22:50

а сейчас снес с система apc но он или ктото другой делает кэш!
удалить не возможно пока папку не снесешь с cache
вернул в настройки xPDOFileCache, префиксы удалять?

Пётр Молчанов

13 ноября 2014, 10:19

можешь оставить. для контроля OPCache рекомендую установить эту панельку gist.github.com/kabel/d12c35bde74814e45c14

Ruslan Butakov

16 декабря 2014, 23:41

Есть сайт порядка 5000 ресурсов, распиханные по контекстам. Есть страница на которой эта вся куча страниц тянется через mFilter2.
… тут немного предыстории, когда сайт еще только начал собираться для себя, все сниппеты вызывались некэшируемыми, и про это дело я забыл, когда ресурсов накопилось очень много, начал искать корень зла долгой обработки данных ДО 20 сек. и наткнулся на это статью, само собой все сделал как описано выше и поставил cache.xPDOAPCCache…

Вроде бы успокоился, но все-равно не мог успокоится по поводу выборки 3к-5к ресурсов за 1-3 секунды, начал рыть снова и уже основательно.
Поставил debugParser, по большой части данное дополнение всетаки заставило меня отказаться от чанков [[$header]] и [[$footer]] — хотя было очень полезно не лазить в каждый шаблон и править какие либо изменения. Далее debugParser показывал что mFilter2 работает медленно 0.6c (но оно и понятно 5к ресурсов, несколько ТВ-параметров в виде фильтров, getImageList + phpthumbon), следом шли pdoMenu и pdoPage 0.09-0.6c на каждого. В итоге все это дело выливалось в 1.0-1.7с парсинга страницы.

Читал, искал, как же все-таки быть, ведь без всего этого мне не обойтись… Пошел смотреть кэширование и проводить эксперементы.
Проверка при 3к ресурсах. Условия не меняю только меняю Класс-обработчик системы кэширования

А дальше самое интересное

1) xPDOFileCache
— первый запуск страницы

Total parse time	2.2206879 s
Total queries	212
Total queries time	0.7438633 s
Memory peak usage	12.5 Mb
 	 
MODX version	MODX Revolution 2.3.2-pl (traditional)
PHP version	5.5.19
Database version	mysql 5.5.34-MariaDB-log
From cache	false

— второй запуск страницы

Total parse time	0.8053942 s
Total queries	83
Total queries time	0.0289793 s
Memory peak usage	10.5 Mb
 	 
MODX version	MODX Revolution 2.3.2-pl (traditional)
PHP version	5.5.19
Database version	mysql 5.5.34-MariaDB-log
From cache	true

2) cache.xPDOAPCCache
— первый запуск страницы

Total parse time	2.1754642 s
Total queries	227
Total queries time	0.6878936 s
Memory peak usage	13.25 Mb
 	 
MODX version	MODX Revolution 2.3.2-pl (traditional)
PHP version	5.5.19
Database version	mysql 5.5.34-MariaDB-log
From cache	false

— второй запуск страницы

Total parse time	1.7597301 s
Total queries	227
Total queries time	0.1033797 s
Memory peak usage	13.25 Mb
 	 
MODX version	MODX Revolution 2.3.2-pl (traditional)
PHP version	5.5.19
Database version	mysql 5.5.34-MariaDB-log
From cache	false

3) cache.xPDOMemCached
— первый запуск страницы

Total parse time	5.4090259 s
Total queries	212
Total queries time	0.8323214 s
Memory peak usage	12.5 Mb
 	 
MODX version	MODX Revolution 2.3.2-pl (traditional)
PHP version	5.5.19
Database version	mysql 5.5.34-MariaDB-log
From cache	false

— второй запуск страницы

Total parse time	0.7800021 s
Total queries	83
Total queries time	0.0112791 s
Memory peak usage	10.5 Mb
 	 
MODX version	MODX Revolution 2.3.2-pl (traditional)
PHP version	5.5.19
Database version	mysql 5.5.34-MariaDB-log
From cache	true

4) cache.xPDOMemCache
— первый запуск страницы

Total parse time	3.3419650 s
Total queries	212
Total queries time	1.5115752 s
Memory peak usage	12.5 Mb
 	 
MODX version	MODX Revolution 2.3.2-pl (traditional)
PHP version	5.5.19
Database version	mysql 5.5.34-MariaDB-log
From cache	false

— второй запуск страницы

Total parse time	0.7741411 s
Total queries	83
Total queries time	0.0100172 s
Memory peak usage	10.5 Mb
 	 
MODX version	MODX Revolution 2.3.2-pl (traditional)
PHP version	5.5.19
Database version	mysql 5.5.34-MariaDB-log
From cache	true

5) ПУСТОЕ ПОЛЕ — Класс-обработчик системы кэширования
— первый запуск страницы

Total parse time	1.9416401 s
Total queries	134
Total queries time	0.1153216 s
Memory peak usage	12.25 Mb
 	 
MODX version	MODX Revolution 2.3.2-pl (traditional)
PHP version	5.5.19
Database version	mysql 5.5.34-MariaDB-log
From cache	false

— второй запуск страницы

Total parse time	0.6672060 s
Total queries	83
Total queries time	0.0460556 s
Memory peak usage	10.5 Mb
 	 
MODX version	MODX Revolution 2.3.2-pl (traditional)
PHP version	5.5.19
Database version	mysql 5.5.34-MariaDB-log
From cache	true

Ruslan Butakov

16 декабря 2014, 23:48

Василий, как считаешь, стоит ли сносить на php5.5 apcu и заменять OPCache, с дальнейшими замерами скорости.

Василий Наумкин

17 декабря 2014, 07:41

Я для себя решил вообще не пользоваться никакими кэшерами из-за их не всегда понятного поведения и возможных глюках в скриптах.

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

Василий Наумкин

17 декабря 2014, 07:56

Чанки [[$header]] и [[$footer]] сами по себе не тормозные — это в них вызывается меню и еще что-то, смотри там дальше по списку.

Во многих сниппетах pdoTools есть возможность указывать глубину выборки &depth, а в меню — уровень &level. Чем они меньше, тем быстрее будут работать.

Во многих сниппетах pdoTools есть параметр &showLog, который выводит подробный лог работы с таймингами и итоговым SQL запросом — нужно смотреть в него и думать, как ускорить, какими параметрами.

Где можно вызывать сниппеты кэшированными — обязательно вызывать их именно такими. Например меню, хлебные крошки.

В конце концов, какие-то места можно переписать на своих сниппетах, потому что pdoTools хоть и универсален, но не идеален.

~~Fi1osof~~

17 декабря 2014, 13:13

Василий, привет!

Не знаю писал здесь кто или нет, не прочитал я все ~150 комментов, но есть такой момент, который у тебя в топике не описан: дело в том, что меняя кеш-хэндлер в настройках (и/или кеш-префикс), возникает проблема повторного использования кешера. Проблема эта связана с тем, что при инициализации MODX еще ничего не знает про твои настройки. Он инициализируется, получает дефолтовый файловый кеш-манагер (ведь он еще не прочитал настройки или кеш настроек, где указан иной кеш-провайдер) и только после того, как у него есть инфа по измененным настройкам кешера, он начинает юзать указанный кешер. Чтобы убедиться в этом попробуй через файловый манагер MODX-а удалить папку core/cache/. Если после удаления не увидишь ее или увидишь там только папку registry, то у тебя все ОК. А если увидишь несколько папок, включая system_seettings и context_settings, то тогда то, о чем я сказал.

На мой взгляд идеального управляющего механизма в MODX на этот счет нет и пока лучшее, что я нашел — это дублировать настройки кешера и префикса в конфиг MODX-а core/config/config.inc.php, там для этого специально заведен массив $config_options. Пишем там:

$config_options = array (
    "cache_prefix"  => "your_prefix_",
    "cache_handler" => "cache.xPDOMemCached",	// Или какой другой хэндлер
);

Вот тогда MODX сразу при инициализации уже будет знать какой кеш-провайдер использовать, и не будет юзать стандартный файловый.

Василий Наумкин

17 декабря 2014, 13:34

Полезная информация, добавил ссылку в заметку.

~~Fi1osof~~

17 декабря 2014, 13:39

Чтобы убедиться в этом попробуй через файловый манагер MODX-а удалить папку core/cache/. Если после удаления не увидишь ее или увидишь там только папку registry, то у тебя все ОК.

Не проверял у себя? Появляется папка с настройками или как? Просто у меня в свое время эта фигня существенно отнимала в производительности сайта.

Василий Наумкин

17 декабря 2014, 13:51

Нет, не проверял.

Давно не пользуюсь кэшерами, потому что на моих небольших проектах от них больше проблем, чем пользы.

~~Fi1osof~~

17 декабря 2014, 14:57

Но здесь же у тебя используется кешер? Вот интересно, есть ли сейчас эта проблема? И если ее вот устранить, производительность повысится или как?

Василий Наумкин

17 декабря 2014, 15:19

Нет, не используется.

Этот сайт у нас на хостинге, там нет никаких твиков — только стандартный PHP 5.5.

~~Fi1osof~~

17 декабря 2014, 15:23

Ясно. ОК.

Wassi Wassinen

23 марта 2015, 17:47

Николай, скажите, а как сюда:

"cache_prefix"  => "your_prefix_",

добавить переменную, которая подхватывала бы префикс из настройки контекста?

Заранее благодарен за ответ.

~~Fi1osof~~

23 марта 2015, 17:57

А никак. Тут замкнутый круг: не была еще получена переменная префикса, чтобы получить настройки контекста, чтобы получить из него настройку префикса. Так что в любом случае придется указывать и там и там.

Wassi Wassinen

23 марта 2015, 18:13

Николай, спасибо за ответ. А что мне в итоге указывать в конфиг. файле? Или каким-то образом указывать несколько?

~~Fi1osof~~

23 марта 2015, 18:29

Ничего несколько не указывается. Логика такая: данная настройка в config.inc.php должна соответствовать используемому префиксу в MODX-е. Возьмите в консоли выполните print $modx->getOption('cache_prefix'); или просто в шаблоне вставьте [[++cache_prefix]], чтобы увидеть какой сейчас префикс используется. И вот это значение и должно быть указано в config.inc.php

Wassi Wassinen

23 марта 2015, 18:36

А, это я понял. :) У меня несколько контекстов, поэтому и спрашиваю.

~~Fi1osof~~

23 марта 2015, 18:42

Для нескольких контекстов особенно не требуется ничего лишнего делать. Сам прейикс не особо страшен в плане производительности. Важен именно тип кеш-провайдера. То есть если у вас, к примеру, memCached, то не страшно, что у разных контекстов разные кеш-префиксы, если в config.inc.php указан именно кеш-провайдер memCached. Будет мелкая потеря на повторном чтении памяти (если префикс у конкретного контекста отличается), но потеря там мизерная. А вот если у вас мемкеш, но по умолчанию используется файловый менеджер, то тут уже при старте MODX использует файловый менеджер, после чего уже поймет что надо использовать мемкеш и тогда только его задействует. Особенно это будет ощущаться при сбросе кеша, когда MODX начала будет кешировать все новые настройки в файлы, читать их и только потом перейдет на память.

Wassi Wassinen

23 марта 2015, 18:48

Николай, спасибо! Искренне благодарен за развернутый ответ. Все стало понятно.

~~Fi1osof~~

23 марта 2015, 18:52

Пожалуйста!

Wassi Wassinen

24 марта 2015, 16:20

Я могу ошибаться, но запятая после

"cache_handler" => "cache.xPDOMemCached",

не нужна?

~~Fi1osof~~

24 марта 2015, 16:36

Без разницы.

Wassi Wassinen

24 марта 2015, 16:56

Спасибо за ответ. Николай, не сталкивались с подобным? modx.pro/help/5122/#comment-36633

~~Fi1osof~~

24 марта 2015, 16:59

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

Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.

Работа с кэшерами в Revolution

Обновлено 17.12.2014

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

Здесь упомянуты