Работа с кэшерами в Revolution
Не все знают, что MODX Revolution умеет работать с разными системами кэширования, для чего применяет следующие классы:
Установка
Рассказывать буду про php-apc, ибо мне он нравится больше всего. Его легко установить и запустить. К тому же, он может войти в ядро php6. К тому же, про установку memcached я уже рассказывал.
Еще особенность: php-apc кэширует скомпилированный php код, а не только пользовательские данные. Это сильно экономит память и повышает отзывчивость.
Ставим на нашу обычную Ubuntu:
Опции 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 установлен по умолчанию.
- xPDOFileCache — стандартный обработчик по умолчанию, хранит кэш в файлах.
- cache.xPDOAPCCache — обработчик для расширения php-apc
- cache.xPDOMemCached — обработчик для memcached. Есть заметка про него
- cache.xPDOMemCache — обработчик для memcache.
- cache.xPDOWinCache — обработчик для wincache. Это для windows хостингов, на IIS.
Установка
Рассказывать буду про php-apc, ибо мне он нравится больше всего. Его легко установить и запустить. К тому же, он может войти в ядро php6. К тому же, про установку memcached я уже рассказывал.
Еще особенность: php-apc кэширует скомпилированный php код, а не только пользовательские данные. Это сильно экономит память и повышает отзывчивость.
Ставим на нашу обычную Ubuntu:
sudo apt-get install php-apc && sudo service php5-fpm restart
Опции 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
Комментарии: 167
Во — а про cache_prefix не знал, спасибо.
Наслышенна тема, но я с ней сталкнулся только на локалке. у меня стоит локальный веб сервер MAMP и в нём по дефолу 3 вида кэша (XCache, eAccelerator и Alternative PHP Cache (APC)) и поигравшись сними я прозрел от APC. После чего дал идею тебе попробовать в живую (хитёр я!!!!, нет просто у меня и так кэшами был апач загручен, а сейчас перенёс всё на nginx и уже после того, как ты подтвердил — всё класс!, установил и себе).
Наслышенна тема, но я с ней сталкнулся только на локалке. у меня стоит локальный веб сервер MAMP и в нём по дефолу 3 вида кэша (XCache, eAccelerator и Alternative PHP Cache (APC)) и поигравшись сними я прозрел от APC. После чего дал идею тебе попробовать в живую (хитёр я!!!!, нет просто у меня и так кэшами был апач загручен, а сейчас перенёс всё на nginx и уже после того, как ты подтвердил — всё класс!, установил и себе).
Нет, проблема оказалась в том, что 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Мб
Итог: Было ~12Мб на главной странице, сейчас 5,34Мб
А стандартные средства кэширование так же будут работать?
Имею ввиду вот такие
Пишем в кэш /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'))
Имею ввиду вот такие
Пишем в кэш /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'))
Ты не понял.
Есть разные обработчики кэша. Если ты включаешь cache.xPDOAPCCache — то все методы работают с ним. Хочешь файлов — гоняй стандартный xPDOFileCache.
Хочешь и то и то — пиши свой обработчик или при кэшировании юзай функции нужного кэшера.
Короче, напрягай фантазию — возможно все.
Есть разные обработчики кэша. Если ты включаешь cache.xPDOAPCCache — то все методы работают с ним. Хочешь файлов — гоняй стандартный xPDOFileCache.
Хочешь и то и то — пиши свой обработчик или при кэшировании юзай функции нужного кэшера.
Короче, напрягай фантазию — возможно все.
Свой класс не обязательно. В 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, точно также можно и разные классы прописать.
Вот статья для ознакомления modx.com/blog/2012/09/24/using-memcached-for-modx-caching/ Там, как видно, Jason Coward кэширует разные элементы в разные истансы memcached, точно также можно и разные классы прописать.
Ну можно еще и так:
$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
Хотя это все насколько я помню, нужно все перепроверять.
$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
Хотя это все насколько я помню, нужно все перепроверять.
Ты чем смотришь то?
class xPDOAPCCache extends xPDOCache
Внутри все методы cacheManager, переопределенные для работы с APC.
https://github.com/modxcms/revolution/blob/develop/core/xpdo/cache/xpdoapccache.class.php
Как это оно работать не будет, когда оно для того и придумано?!
class xPDOAPCCache extends xPDOCache
Внутри все методы cacheManager, переопределенные для работы с APC.
https://github.com/modxcms/revolution/blob/develop/core/xpdo/cache/xpdoapccache.class.php
Как это оно работать не будет, когда оно для того и придумано?!
Изучаю PHPStorm, глянь чего он умеет, круто
i45.fastpic.ru/big/2012/1015/cf/85d1d5879647384e1047a49e54d709cf.png
i45.fastpic.ru/big/2012/1015/cf/85d1d5879647384e1047a49e54d709cf.png
Так я не после, я во время.
Сначала глубоко поучил PHP, потом стало скучно — полез читать про другое. Но значительных прелестей не обнаружил и пока забросил.
Как встречу что-то, чего не могу (но должен) сделать на PHP — вернусь к обучению.
Пока все силы предпочитаю тратить на работу с PHP в целом, и MODX Revolution, в частности — так каждый день открытия.
Сначала глубоко поучил PHP, потом стало скучно — полез читать про другое. Но значительных прелестей не обнаружил и пока забросил.
Как встречу что-то, чего не могу (но должен) сделать на PHP — вернусь к обучению.
Пока все силы предпочитаю тратить на работу с PHP в целом, и MODX Revolution, в частности — так каждый день открытия.
Ваня, привет!
Если тебе нужен именно файловый кеш-манагер (мне такое часто надо, не смотря на то, что используется мем-кешер, просто для того, чтобы что-то в файлы записывать и не заморачиваться с наличием директорий:)), то ты можешь несколько вариантов использовать.
Самый простой — это просто через $modx->getService() или new $className() (это ты и сам знаешь), но есть более правильный путь — юзать $modx->cacheManager->getProvider(). Просто MODX умеет одновременно работать с несколькими провайдерами. При этом есть вот такой вариант:
Но в данном случае не совсем удобно то, что если будет желание еще в каком-то месте с ним поработать, то надо будет опять юзать getCacheProvider(). Вот другой вариант:
Если тебе нужен именно файловый кеш-манагер (мне такое часто надо, не смотря на то, что используется мем-кешер, просто для того, чтобы что-то в файлы записывать и не заморачиваться с наличием директорий:)), то ты можешь несколько вариантов использовать.
Самый простой — это просто через $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);Но в данном случае не совсем удобно то, что если будет желание еще в каком-то месте с ним поработать, то надо будет опять юзать 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",
));
До https://loadimpact.com/load-test/gadgets.lg.ua-32641fb4d2c85ed3d465c7cc1a5293a7
После loadimpact.com/load-test/gadgets.lg.ua-68d6d7b1da2561b278d46aa9999e47aa
После loadimpact.com/load-test/gadgets.lg.ua-68d6d7b1da2561b278d46aa9999e47aa
gadgets.lg.ua/catalog/tablets/chuwi-v99/
Загрузка страницы: 8,0703 s
Память: 7,14 Мб
8 сек это очень много
Загрузка страницы: 8,0703 s
Память: 7,14 Мб
8 сек это очень много
на странице происходит вызов:
[[!msGetGoodsPlaceholders]], [[msGetGallery]], [[!LikeDislike]], [[getRelated]], [[TvList]], [[getViewed]] и еще несколько чанков. Проблему нашел: msGetGallery увеличивает загрузку на 4сек, getViewed еще где-то на 1.5с и getRelated 1.5с. Выключив всё это, результат 1сек без кэша.
[[!msGetGoodsPlaceholders]], [[msGetGallery]], [[!LikeDislike]], [[getRelated]], [[TvList]], [[getViewed]] и еще несколько чанков. Проблему нашел: msGetGallery увеличивает загрузку на 4сек, getViewed еще где-то на 1.5с и getRelated 1.5с. Выключив всё это, результат 1сек без кэша.
Отправил на почту свой вариант, и еще я не использую сниппет phpthumbof, а написал свой маленький который работает с Imagick, он при аплоаде изменяет сразу фотку на нужные размеры, а если вы заливали через фтп, то в вызове сниппета просто указываете размеры изображений, &size=`150x150`, и все, он создает папку thumbs там где лежит фотка и туда записывает уменьшенное изображение
Работает, однако в логах у меня теперь «сыпит» ошибками:
[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».
[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».
Только как три дня разобрался с проблемой из за APC… Делаю сайт на рево, инет-магазин (используется шопкипер, мини-шоп пока не тестировал), домашний образ убунты — все окей, а на сервере не работает (петерхост) корзина- или не обновляется или во время добавления ошибка. После нескольких дней мучений наконец-то вставил в htaccess apc.cache_by_default off и все заработало!
А может быть просто надо было изменить класс в натройках Modx? Или это все таки косяк разработчиков? Если да — надо на форме попросить, чтобы они доработали скрипт для работы с php-apc.
А может быть просто надо было изменить класс в натройках Modx? Или это все таки косяк разработчиков? Если да — надо на форме попросить, чтобы они доработали скрипт для работы с php-apc.
Любопытства ради проделал данную операцию, но вот беда:
захожу в настройки 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'
В настройках системы Статус сайта=Нет.
Кнопку очистить кэш нажимал не один раз, но это не помогает.
Это у всех так или только у меня?
захожу в настройки 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'
В настройках системы Статус сайта=Нет.
Кнопку очистить кэш нажимал не один раз, но это не помогает.
Это у всех так или только у меня?
я не внимательно прочитал ваш коммент выше, я понял, что после очистки папки cache у вас всё работает правильно?
Я не проверял с статусом сайта, но после изменения системных настроек, языковых файлов и.т.д., я всегда удаляю папку cache (к стате, самый быстрый способ очистить содержимое папки — в дереве файловой системы, просто удаляем папку core/cache она сразу автоматом создаётся с обновленными системными настройками.)
Я не проверял с статусом сайта, но после изменения системных настроек, языковых файлов и.т.д., я всегда удаляю папку cache (к стате, самый быстрый способ очистить содержимое папки — в дереве файловой системы, просто удаляем папку core/cache она сразу автоматом создаётся с обновленными системными настройками.)
Угу, после удаление файлов из папки core/cache все нормально.
Вероятно это из-за того что выбран тип cache.xPDOAPCCache.
Еще я пытался «играться с настройками», заходил в контексты и создавал там параметр cache_prefix с (web & mrg — сразу и по отдельности) одинаковыми параметрами, в результате настройки сохраняются и без удаления core/cache, но опять же есть проблема, которая не позволяет это использовать, а именно:
«Иначе, все данные будут кэшироваться без уникального префикса, и на одном сайте вылезет кэш от другого. Будет не круто, уверяю.»
Т.е. у меня на 3 сайтах был 1 и тот же сайт.
На modx.com попадалась статья на англ. языке, из которой, как я понял опять же, эта проблема связана именно с типом кэша.
Вероятно это из-за того что выбран тип cache.xPDOAPCCache.
Еще я пытался «играться с настройками», заходил в контексты и создавал там параметр cache_prefix с (web & mrg — сразу и по отдельности) одинаковыми параметрами, в результате настройки сохраняются и без удаления core/cache, но опять же есть проблема, которая не позволяет это использовать, а именно:
«Иначе, все данные будут кэшироваться без уникального префикса, и на одном сайте вылезет кэш от другого. Будет не круто, уверяю.»
Т.е. у меня на 3 сайтах был 1 и тот же сайт.
На modx.com попадалась статья на англ. языке, из которой, как я понял опять же, эта проблема связана именно с типом кэша.
Да, есть такой баг, но.
Если указать у web и mgr один префикс, и он будет уникальным для этого сайта — то должно работать.
А у другого сайта другие префиксы для mgr и web, но между собой одинаковые.
В любом случае, такой кэш надо включать на готовом сайте, во время разработки он только мешает.
Если указать у web и mgr один префикс, и он будет уникальным для этого сайта — то должно работать.
А у другого сайта другие префиксы для mgr и web, но между собой одинаковые.
В любом случае, такой кэш надо включать на готовом сайте, во время разработки он только мешает.
«Если указать у web и mgr один префикс, и он будет уникальным для этого сайта — то должно работать.
А у другого сайта другие префиксы для mgr и web, но между собой одинаковые.»
Именно так и пытался сделать, сначала создается впечатление что все работает, но потом:
«Иначе, все данные будут кэшироваться без уникального префикса, и на одном сайте вылезет кэш от другого. Будет не круто, уверяю.»
Возможно это только у меня так, поэтому спросил у кого есть возможность проверить у себя на сайте, чтобы внести хоть какую-то ясность в это для всех.
А у другого сайта другие префиксы для mgr и web, но между собой одинаковые.»
Именно так и пытался сделать, сначала создается впечатление что все работает, но потом:
«Иначе, все данные будут кэшироваться без уникального префикса, и на одном сайте вылезет кэш от другого. Будет не круто, уверяю.»
Возможно это только у меня так, поэтому спросил у кого есть возможность проверить у себя на сайте, чтобы внести хоть какую-то ясность в это для всех.
Интересный момент в настройках постраничной навигации с помощью getPage.
Сам сниппет и его плейсхолдер требуют не кэшированного вызова. Однако в параметрах есть настройки для кэширования. Попробовал их включить и вызвать getPage@paramName (paramName — пользователькие настройки).
Время генерации страницы на каталоге MS 1 c выводом 25 наименований упало с 0.7 до 0.18
Сам сниппет и его плейсхолдер требуют не кэшированного вызова. Однако в параметрах есть настройки для кэширования. Попробовал их включить и вызвать getPage@paramName (paramName — пользователькие настройки).
Время генерации страницы на каталоге MS 1 c выводом 25 наименований упало с 0.7 до 0.18
Это вроде из-за того что MODX по умолчанию использует пользовательский обработчик для сессии и при завершении PHP он разрушается раньше, чем успевают записаться последние изменения в сессии, которые APC видимо кэширует.
Попробуйте создать плагин на событие OnInitCulture
Попробуйте создать плагин на событие OnInitCulture
<?php
register_shutdown_function('session_write_close');
После неудачной попытки с php-apc вернулся на стандартный кэшер —
1. Раскомментировал строку
3. Удалил префикс.
4. Почистил все кеши на всякий.
Но в итоге все равно redirect_uri_mismatch. А php-apc не отключается судя по php-info:
Василий, без твоей помощи не обойтись.
1. Раскомментировал строку
ini_set('apc.cache_by_default', 'Off'); // Отключение кэширования php-apc3. Удалил префикс.
4. Почистил все кеши на всякий.
Но в итоге все равно redirect_uri_mismatch. А php-apc не отключается судя по php-info:
Василий, без твоей помощи не обойтись.
Ура, заработало! В .htaccess разкомментировал переадресацию с www.site.ru на site.ru (закомментировал позавчера для корректной индексации Яндексом зеркал по рекомендации службы поддержки Яндекса). Странно, я во всех сервисах указываю без www. Почему Яндекс, Гугле, Фейсбук добавляют в адрес www не понятно.
Поставил-таки php-apc, включил нужный кешер в настройках. Всё стало работать шустрее, но существует эта долбанная проблема с сессиями:
1. hybrid работает тока при ini_set('apc.cache_by_default', 0); в индекс файле. это разве не отключает кешер для всего сайта?
2. после регистрации пользователь автоматически не залогинивается и к тому же пароль на почту приходит в закодированном виде.
Не хотелось бы отказываться от этого кешера, т.к. работает шустро и развитие в любом случае будет. Василий, могли бы вы чем-нибудь помочь, подсказать где копнуть? Отключал кеширование БД и сессий (с удалением /core/cache/), но не помогает…
1. hybrid работает тока при ini_set('apc.cache_by_default', 0); в индекс файле. это разве не отключает кешер для всего сайта?
2. после регистрации пользователь автоматически не залогинивается и к тому же пароль на почту приходит в закодированном виде.
Не хотелось бы отказываться от этого кешера, т.к. работает шустро и развитие в любом случае будет. Василий, могли бы вы чем-нибудь помочь, подсказать где копнуть? Отключал кеширование БД и сессий (с удалением /core/cache/), но не помогает…
Удалось запустить на этом 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"
Скажите, при авторизации через 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 и по-этому можно юзать этот тип кеширования?
я быстро нашёл в поиске, что для этого нужно в index.php добавить ini_set('apc.cache_by_default', 'Off'); // Отключение кэширования php-apc
вставил, глюк пропал.
но ведь не может же быть, чтоб HybridAuth не мог в принципе работать с php-apc.
или мы добавив в индекс отключение apc.cache_by_default вырубаем его не для всей cms и по-этому можно юзать этот тип кеширования?
Ребята привет. Подскажите как APC кешер отключить на сервере под фряхой?
ни ini_set('apc.cache_by_default', 'Off') в index.php
ни php_flag apc.cache_by_default off в .htaccess
ничего не помогает. Кеширует все наглухо…
если перевести modx с файлового кешера на apc — тоже результатов нет…
что еще можно попробовать?
ни ini_set('apc.cache_by_default', 'Off') в index.php
ни php_flag apc.cache_by_default off в .htaccess
ничего не помогает. Кеширует все наглухо…
если перевести modx с файлового кешера на apc — тоже результатов нет…
что еще можно попробовать?
Из кешеров только APC увидел — joxi.ru/wOmuUv3JTJDIMB-xAvs
Насчет opcache есть вот такие упоминания и все — joxi.ru/lOmuUv3JTJB-L7TmHuA
ОНО?
Так как странички реально морозятся на долгое время, кеш удалил — уже почти два часа прошло, а страницы так и не обновились.
Насчет opcache есть вот такие упоминания и все — joxi.ru/lOmuUv3JTJB-L7TmHuA
ОНО?
Так как странички реально морозятся на долгое время, кеш удалил — уже почти два часа прошло, а страницы так и не обновились.
Поставил apc-php
префикс добавил, кэш вроде создается
но при очистки кэша из админки выдает
prntscr.com/55bvcp
префикс добавил, кэш вроде создается
но при очистки кэша из админки выдает
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.
можешь оставить. для контроля OPCache рекомендую установить эту панельку gist.github.com/kabel/d12c35bde74814e45c14
Есть сайт порядка 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
— первый запуск страницы
— первый запуск страницы
— первый запуск страницы
— первый запуск страницы
— первый запуск страницы
… тут немного предыстории, когда сайт еще только начал собираться для себя, все сниппеты вызывались некэшируемыми, и про это дело я забыл, когда ресурсов накопилось очень много, начал искать корень зла долгой обработки данных ДО 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 falseTotal 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— первый запуск страницы
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 falseTotal 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— первый запуск страницы
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 falseTotal 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— первый запуск страницы
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 falseTotal 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— первый запуск страницы
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 falseTotal 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
Я для себя решил вообще не пользоваться никакими кэшерами из-за их не всегда понятного поведения и возможных глюках в скриптах.
Лучше оптимизировать код, чем полагаться на эти кэшеры. Возможно, изменю своё мнение, если буду делать реальный hi-load проект, но пока что таких не было.
Лучше оптимизировать код, чем полагаться на эти кэшеры. Возможно, изменю своё мнение, если буду делать реальный hi-load проект, но пока что таких не было.
Чанки [[$header]] и [[$footer]] сами по себе не тормозные — это в них вызывается меню и еще что-то, смотри там дальше по списку.
Во многих сниппетах pdoTools есть возможность указывать глубину выборки &depth, а в меню — уровень &level. Чем они меньше, тем быстрее будут работать.
Во многих сниппетах pdoTools есть параметр &showLog, который выводит подробный лог работы с таймингами и итоговым SQL запросом — нужно смотреть в него и думать, как ускорить, какими параметрами.
Где можно вызывать сниппеты кэшированными — обязательно вызывать их именно такими. Например меню, хлебные крошки.
В конце концов, какие-то места можно переписать на своих сниппетах, потому что pdoTools хоть и универсален, но не идеален.
Во многих сниппетах pdoTools есть возможность указывать глубину выборки &depth, а в меню — уровень &level. Чем они меньше, тем быстрее будут работать.
Во многих сниппетах pdoTools есть параметр &showLog, который выводит подробный лог работы с таймингами и итоговым SQL запросом — нужно смотреть в него и думать, как ускорить, какими параметрами.
Где можно вызывать сниппеты кэшированными — обязательно вызывать их именно такими. Например меню, хлебные крошки.
В конце концов, какие-то места можно переписать на своих сниппетах, потому что pdoTools хоть и универсален, но не идеален.
Василий, привет!
Не знаю писал здесь кто или нет, не прочитал я все ~150 комментов, но есть такой момент, который у тебя в топике не описан: дело в том, что меняя кеш-хэндлер в настройках (и/или кеш-префикс), возникает проблема повторного использования кешера. Проблема эта связана с тем, что при инициализации MODX еще ничего не знает про твои настройки. Он инициализируется, получает дефолтовый файловый кеш-манагер (ведь он еще не прочитал настройки или кеш настроек, где указан иной кеш-провайдер) и только после того, как у него есть инфа по измененным настройкам кешера, он начинает юзать указанный кешер. Чтобы убедиться в этом попробуй через файловый манагер MODX-а удалить папку core/cache/. Если после удаления не увидишь ее или увидишь там только папку registry, то у тебя все ОК. А если увидишь несколько папок, включая system_seettings и context_settings, то тогда то, о чем я сказал.
На мой взгляд идеального управляющего механизма в MODX на этот счет нет и пока лучшее, что я нашел — это дублировать настройки кешера и префикса в конфиг MODX-а core/config/config.inc.php, там для этого специально заведен массив $config_options. Пишем там:
Не знаю писал здесь кто или нет, не прочитал я все ~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-а удалить папку core/cache/. Если после удаления не увидишь ее или увидишь там только папку registry, то у тебя все ОК.Не проверял у себя? Появляется папка с настройками или как? Просто у меня в свое время эта фигня существенно отнимала в производительности сайта.
Нет, не используется.
Этот сайт у нас на хостинге, там нет никаких твиков — только стандартный PHP 5.5.
Этот сайт у нас на хостинге, там нет никаких твиков — только стандартный PHP 5.5.
Ничего несколько не указывается. Логика такая: данная настройка в config.inc.php должна соответствовать используемому префиксу в MODX-е. Возьмите в консоли выполните print $modx->getOption('cache_prefix'); или просто в шаблоне вставьте [[++cache_prefix]], чтобы увидеть какой сейчас префикс используется. И вот это значение и должно быть указано в config.inc.php
Для нескольких контекстов особенно не требуется ничего лишнего делать. Сам прейикс не особо страшен в плане производительности. Важен именно тип кеш-провайдера. То есть если у вас, к примеру, memCached, то не страшно, что у разных контекстов разные кеш-префиксы, если в config.inc.php указан именно кеш-провайдер memCached. Будет мелкая потеря на повторном чтении памяти (если префикс у конкретного контекста отличается), но потеря там мизерная. А вот если у вас мемкеш, но по умолчанию используется файловый менеджер, то тут уже при старте MODX использует файловый менеджер, после чего уже поймет что надо использовать мемкеш и тогда только его задействует. Особенно это будет ощущаться при сбросе кеша, когда MODX начала будет кешировать все новые настройки в файлы, читать их и только потом перейдет на память.
Спасибо за ответ. Николай, не сталкивались с подобным? modx.pro/help/5122/#comment-36633
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Здесь упомянуты:
| Компонент | Текущая версия | Закачки |
| miniShop2 | 4.4.0-pl от 06.08.2024 | 26 091 |
| pdoTools | 2.13.2-pl от 02.09.2021 | 54 158 |
| mSearch2 | 1.14.11-pl от 02.05.2023 | 18 901 |
| Loginza | 1.3.2-pl от 24.05.2013 | 472 |
| Tickets | 1.13.0-pl от 10.03.2020 | 19 558 |
| HybridAuth | 3.1.1-pl от 27.10.2024 | 6 909 |
| debugParser | 1.1.0-pl от 26.08.2015 | 2 011 |
| phpThumbOn | 1.3.5-beta2 от 12.02.2019 | 11 652 |
16 ноября 2024, 21:12
Спасибо. Работает.
16 ноября 2024, 20:54
Владимир, добрый день!
Есть возможность добавить в модуль функцию отмены заказа?
Т.е. если в админке магазине поставили статус Отменен, чтобы в Ти...
15 ноября 2024, 17:40
спасибо, несколько раз проверял и не заметил)
14 ноября 2024, 13:55
Сложна.
Я сделал с помощью js. Задал class для div c results
и вот так прописал
document.querySelector('.easycomm div').textContent = 'Отзывов пок...
14 ноября 2024, 11:50
Добрый день! Установил MarkdownEditorFrontend с modstore и xpdo выдало ошибку что не может найти сервис. К моему удивлению в транспортном пакете не на...
14 ноября 2024, 05:22
astro.build впервые слышу такой фреймворк. Вообще gtsAPI затачивался под primevue.org. Но в primevue вообще не никакой связи с api. Там api как хочешь...
13 ноября 2024, 10:55
Не все пожелания клиента нужно реализовывать. Одно дело когда желание обосновано бизнес-процессами, а другое дело клиент так видит. В данном случае, н...
