Документация для специалистов

Эксперименты и исследования

Blog by Fi1osof

Еще одна фишка с кешированием в Smarty

Еще немного о кешировании в MODX Revolution

Кеширование настроек контекстов в MODX Revolution. Я негодую

Не оправдано большой кеш страниц.

MODX Revolution + nginx + memcached.

Натолкнул я тебя на мысль посмотреть на смарти и ты нашел там совсем другую плюшку -)
 Спасибо, не знал.

Натолкнул я тебя на мысль посмотреть на смарти и т

Нет, это не твоя мысль совсем, не присваивай :-)
 Если ты про {php}, то я ее даже и не смотрел. А историю того, как я к этому пришел, я написал в топике.

Нет, это не твоя мысль совсем, не присваивай :-)
 

Да я тролю в силу того, что две мысли о смарти в один день появились.
 И, кстати, {php} не пашет, погляди на досуге, плиз. Возможно не пашет в силу того, что сам шаблон в modx тоже с PHP. И получается, по первому мнению, эдакая рекурсия, что апач нагружается на 100% и вылетает по «бесконечному циклу».

Да я тролю в силу того, что две мысли о смарти в о

Ребята, включайте вывод ошибок на дев-серверах. Как вы так работаете без отладки? Вслепую?
 Пишет же четко:
 

Fatal error: Uncaught exception 'SmartyException' with message '{php} is deprecated, set allow_php_tag = true to enable

В контроллере или в плагине пропишите $modx->smarty->allow_php_tag = true; и будет вам счастье.

Ребята, включайте вывод ошибок на дев-серверах. Как вы так работаете без отладки? Вслепую?
 Пишет же четко: Fatal error: Uncaught exception 'SmartyException' with message '{php} is deprecated, set allow_php_tag = true to enable В контроллере или в плагине пропишите $modx->smarty->allow_php_tag = true; и будет вам счастье.

Ребята, включайте вывод ошибок на дев-серверах. Ка

В слепую, на высоком уровне доверия к разработчикам. А затем начинается гадание: кто виноват, мля??? =)
 Спасибо. Пойду включать неэстетичный вывод ошибок.

В слепую, на высоком уровне доверия к разработчика

Неэстетичный — это к дизайнерам. А для программиста отладка — его всё.

Неэстетичный — это к дизайнерам. А для программист

А где ты видел отдельно дизайнера отладочных интерфейсов? Вызов принят, надо эстетики навесить на вывод ошибок.

А где ты видел отдельно дизайнера отладочных интер

Ну, я вот вообще далекий от эстетики человек. А к примеру artdevue — он и программер хороший, и с дизайном дружит.

Ну, я вот вообще далекий от эстетики человек. А к 

У меня такой вопрос, беря во внимание эту статью, первый пункт, мы можем добавлять идентификатор cache только в {include file}? Тогда все таки придется шаблон распилить на файлы? или можно воспользоваться блоком? что то типо этого:
 

        {* Header *}
{block name=header cache="header"}
<a id="logo" title="{$site_name}" href="/"></a>

<nav id="menu">
    {assign var=params value=[
        "startId"       => 0
        ,"level"        => 1
        ,"cacheable"    => true
        ,"id"           => "mainMenu"
    ]}
                    
    {processor action="web/menu/getcatalogmenu" ns="hamster" params=$params assign=result}
    {assign var=items value=$result.object}
    {include file="inc/menu/catalog/outer.               
</nav>

<div id="phone_order">
    Заказ по телефону:<br />+7 (495) 221-90-21<br />+7 (495) 221-90-23<br />+7 (925) 092-28-33
</div>

<div id="user_panel">
	<a id="cartLink" href="{link id=4}" title="Корзина">Корзина</a>
	<span class="uLogin">[[!uLogin? &providers="vkontakte,facebook,odnoklassniki,twitter,mailru,google" &hidden="" &userGroups="Authorized" ]]</span>
</div>
{/block}
        {* Eof Header *}


У меня такой вопрос, беря во внимание эту статью, первый пункт, мы можем добавлять идентификатор cache только в {include file}? Тогда все таки придется шаблон распилить на файлы? или можно воспользоваться блоком? что то типо этого: {block name=header cache="header"} То есть вот так: {* Header *}
{block name=header cache="header"}
<a id="logo" title="{$site_name}" href="/"></a>

<nav id="menu">
    {assign var=params value=[
        "startId"       => 0
        ,"level"        => 1
        ,"cacheable"    => true
        ,"id"           => "mainMenu"
    ]}
                    
    {processor action="web/menu/getcatalogmenu" ns="hamster" params=$params assign=result}
    {assign var=items value=$result.object}
    {include file="inc/menu/catalog/outer.               
</nav>

<div id="phone_order">
    Заказ по телефону:<br />+7 (495) 221-90-21<br />+7 (495) 221-90-23<br />+7 (925) 092-28-33
</div>

<div id="user_panel">
	<a id="cartLink" href="{link id=4}" title="Корзина">Корзина</a>
	<span class="uLogin">[[!uLogin? &providers="vkontakte,facebook,odnoklassniki,twitter,mailru,google" &hidden="" &userGroups="Authorized" ]]</span>
</div>
{/block}
        {* Eof Header *}

У меня такой вопрос, беря во внимание эту статью, 

или можно воспользоваться блоком? что то типо этого:

Нет. Судя по документации в блоке можно указать nocache. Это надо только при включенном глобальном кешировании Smarty. Но нельзя как подшаблону указать cache_id.
 А что тебе не нравится закинуть это в отдельный файл? Если это кешируемый подшаблон, то все равно он не будет каждый раз подгружаться (файл подшаблона). Будет вызываться метод Smarty, который будет проверять наличие кеша, и возвращать его, если он есть.

или можно воспользоваться блоком? что то типо этого: Нет. Судя по документации в блоке можно указать nocache. Это надо только при включенном глобальном кешировании Smarty. Но нельзя как подшаблону указать cache_id.
 А что тебе не нравится закинуть это в отдельный файл? Если это кешируемый подшаблон, то все равно он не будет каждый раз подгружаться (файл подшаблона). Будет вызываться метод Smarty, который будет проверять наличие кеша, и возвращать его, если он есть.

или можно воспользоваться блоком? что то типо этог

Смотрю за тобой уже давно и смотрю сколько полезных и интересных статей написал)
 Сам делаю сайты на MODX REVO, больше front-end разработчик.
 Так вот, руки опускаются, когда понимаю, что в модх большая проблема с кэшем.
 Добавляешь новую страницу в админку, почисти весь кэш, а если 5000 ресурсов тогда сколько ресурсозатрат будет.
 Нет, для простых сайтов визиток и корпоративных сайтов проблем не возникает, но хочется сделать нечто больше по количеству страниц.
 И тут понимаю, что встречаю вилы. Система самому нравится, за гибкость в работе верстальщика, в отличие от других систем.
 Защищенность, сколько не работаю с модх — ломают очень редко в отличии от кривой джумблы и дырявого вордпресса.
 

Так вот для кэша ставил специальный плагин, который при добавлении страницы не очищал весь кэш, потом ставил кэш обновлялку.
 Пробовал этот метод:
 modx.im/blog/addons/663.html — кстати очень понравился в плане скорости, но есть ряд ограничений.
 Но это же костыли(, 
 

Интересно разработчики в modx3 сделают нормальную систему кэширования и более гибкую админку + возможность легкого создания пользовательских таблиц.

Смотрю за тобой уже давно и смотрю сколько полезных и интересных статей написал)
 Сам делаю сайты на MODX REVO, больше front-end разработчик.
 Так вот, руки опускаются, когда понимаю, что в модх большая проблема с кэшем.
 Добавляешь новую страницу в админку, почисти весь кэш, а если 5000 ресурсов тогда сколько ресурсозатрат будет.
 Нет, для простых сайтов визиток и корпоративных сайтов проблем не возникает, но хочется сделать нечто больше по количеству страниц.
 И тут понимаю, что встречаю вилы. Система самому нравится, за гибкость в работе верстальщика, в отличие от других систем.
 Защищенность, сколько не работаю с модх — ломают очень редко в отличии от кривой джумблы и дырявого вордпресса. Так вот для кэша ставил специальный плагин, который при добавлении страницы не очищал весь кэш, потом ставил кэш обновлялку.
 Пробовал этот метод:
 modx.im/blog/addons/663.html — кстати очень понравился в плане скорости, но есть ряд ограничений.
 Но это же костыли(, Интересно разработчики в modx3 сделают нормальную систему кэширования и более гибкую админку + возможность легкого создания пользовательских таблиц.

Смотрю за тобой уже давно и смотрю сколько полезны

В принципе, если сайт планируется большой, и предполагается большое количество кеш-файлов, то почти на 100% спасает переход на мемори-кеш-провайдер (memcache или APC). Ведь сам по себе большой общий кеш не страшен, а вот сброс его, это да, сервер сделает плакать, когда там десятки тысяч файлов. А на memcache или APC сброс почти мгновенный. Так же частенько использую заплатку cacheOptimizer. Когда страниц много и кеш-карта ресурсов разрастается (а так же начинает жутко тормозить на редактировании документов и сбросе кеша, так как MODX каждый раз запрашивает из базы данных все ресурсы и набивает их в в кеш контекста), тоже очень здорово помогает (отключает карту ресурсов полностью, и тогда на нее вообще нет запросов). Правда само собой MODX-у приходится запрашиваемую страницу искать в базе данных, но по моему опыту с магазином на 150 000+ товаров, что я сейчас делаю — это вообще не проблема.
 

Резюме: даже сейчас MODX все равно позволяет делать сайты с загрузкой не более 0,4 сек (для большого сайта можно сказать со скрипом, что это нормально).  
 А в новой версии MODX-а нас действительно ждут улучшения. И они даже не с самого MODX-а ожидаются, а больше с xPDO новой версии. Там Джейсон обещает более скоростную работу. Принцип работы xPDO поменяется, новые технологии применятся, автозагрузка и т.п. У него уже сейччас есть серьезные наработки и он очень доволен результатом.

В принципе, если сайт планируется большой, и предполагается большое количество кеш-файлов, то почти на 100% спасает переход на мемори-кеш-провайдер (memcache или APC). Ведь сам по себе большой общий кеш не страшен, а вот сброс его, это да, сервер сделает плакать, когда там десятки тысяч файлов. А на memcache или APC сброс почти мгновенный. Так же частенько использую заплатку cacheOptimizer. Когда страниц много и кеш-карта ресурсов разрастается (а так же начинает жутко тормозить на редактировании документов и сбросе кеша, так как MODX каждый раз запрашивает из базы данных все ресурсы и набивает их в в кеш контекста), тоже очень здорово помогает (отключает карту ресурсов полностью, и тогда на нее вообще нет запросов). Правда само собой MODX-у приходится запрашиваемую страницу искать в базе данных, но по моему опыту с магазином на 150 000+ товаров, что я сейчас делаю — это вообще не проблема. Резюме: даже сейчас MODX все равно позволяет делать сайты с загрузкой не более 0,4 сек (для большого сайта можно сказать со скрипом, что это нормально).  
 А в новой версии MODX-а нас действительно ждут улучшения. И они даже не с самого MODX-а ожидаются, а больше с xPDO новой версии. Там Джейсон обещает более скоростную работу. Принцип работы xPDO поменяется, новые технологии применятся, автозагрузка и т.п. У него уже сейччас есть серьезные наработки и он очень доволен результатом.

В принципе, если сайт планируется большой, и предп

Вот по этому пунктку, плиз, подробнее.
 

А в новой версии MODX-а нас действительно ждут улучшения. 

Собственно 
 1. когда, 
 2. что изменится, 
 3. будет ли обратная поддержка старых сайтов (то есть обновление убьет сайт и его придется переписывать) 
 ?

Вот по этому пунктку, плиз, подробнее. А в новой версии MODX-а нас действительно ждут улучшения. Собственно 
 1. когда, 
 2. что изменится, 
 3. будет ли обратная поддержка старых сайтов (то есть обновление убьет сайт и его придется переписывать) 
 ?

Вот по этому пунктку, плиз, подробнее. А в новой в

А вот это только когда выйдет. Сейчас нет четкой информации и нет даже четкого релиза. Так что все ждем с закрытыми глазами.

А вот это только когда выйдет. Сейчас нет четкой и

Молодец! все толково расписал. Насчет только для визиток, я бы не был так категоричен. Nginx много чего умеет…

Молодец! все толково расписал. Насчет только для в

Так я сказал «пока». Докрутить многое можно. Да и на уровне плагина можно разрулить что кешировать так, а что нет (допустим, личный кабинет не кешировать). 
 Но это так, эксперимент. Я более плотно планирую делать это на уровне node.js То есть нода не все еще умеет, чтобы так сразу фрейм заменить, но ее можно использовать как умный кешер. То есть и данные в памяти держать, и логику рулить можно. В общем, планирую nginx+MODX+node.js

Так я сказал «пока». Докрутить многое можно. Да и 

memcache зараза страницу компрессирует как ни крути, а вот с memcached все нормально)
 вот это у тебя 

вообще лишнее, можно выкинуть…
 и добавить еще $expire 

<code>$modx->cacheManager->set($key , $modx->resource->_output, $expire);</code>

выставить время жизни кеша.
 и в nginx правильнее наверно будет 

memcache зараза страницу компрессирует как ни крути, а вот с memcached все нормально)
 вот это у тебя <code>$key = '/index.php?';</code> вообще лишнее, можно выкинуть…
 и добавить еще $expire <code>$modx->cacheManager->set($key , $modx->resource->_output, $expire);</code> выставить время жизни кеша.
 и в nginx правильнее наверно будет "default/$args"

memcache зараза страницу компрессирует как ни крут

memcache зараза страницу компрессирует как ни крути

А ты смотри phpinfo() раздел memcache. У него тоже свои настройки есть, типа max_chunk_size или типа того. Наверняка тоже можно поднять значение.
 

вообще лишнее, можно выкинуть…

и в nginx правильнее наверно будет
 «default/$args»

Да? А кто запрещает создать еще какой-нибудь внутренний php-файл? И что тогда? И тогда нафиг все побьется. А ты предлагаешь все жестко завязать на единственный php-файл. Не, я так не буду делать.
 

Это я может позже поковыряю, но у меня есть подозрение, что это не так работает, как хотелось бы. Думаю, что это значение для самого MODX-а, а не для мемкеша. То есть как работает этот параметр для MODX-а? — кеш есть, но время уже не актуальное, и MODX его игнорит. Но если это так, то gnixn-у на это пофигу будет, он получит кеш и все. Хотя это только предположение, проверять надо.

memcache зараза страницу компрессирует как ни крути А ты смотри phpinfo() раздел memcache. У него тоже свои настройки есть, типа max_chunk_size или типа того. Наверняка тоже можно поднять значение. вообще лишнее, можно выкинуть… и в nginx правильнее наверно будет
 «default/$args» Да? А кто запрещает создать еще какой-нибудь внутренний php-файл? И что тогда? И тогда нафиг все побьется. А ты предлагаешь все жестко завязать на единственный php-файл. Не, я так не буду делать. и добавить еще $expire Это я может позже поковыряю, но у меня есть подозрение, что это не так работает, как хотелось бы. Думаю, что это значение для самого MODX-а, а не для мемкеша. То есть как работает этот параметр для MODX-а? — кеш есть, но время уже не актуальное, и MODX его игнорит. Но если это так, то gnixn-у на это пофигу будет, он получит кеш и все. Хотя это только предположение, проверять надо.

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

насчет побьется я не совсем уверен, так как неделю назад вообще про nginx не слышал. Но я думаю ты ошибаешся… Пройдись по конфигу nginx и посмотри логику.
 

$expire работает — уже проверял.

да настройки есть конечно, аналогичные кстати… но не получилось, возможно механизм сжатия по другому работает. насчет побьется я не совсем уверен, так как неделю назад вообще про nginx не слышал. Но я думаю ты ошибаешся… Пройдись по конфигу nginx и посмотри логику. $expire работает — уже проверял.

да настройки есть конечно, аналогичные кстати… но 

насчет побьется я не совсем уверен, так как неделю назад вообще про nginx не слышал. Но я думаю ты ошибаешся… Пройдись по конфигу nginx и посмотри логику.

Я вчера часов 6 с этим конфигом провозился, так что испробовал различные варианты. Смотри вот правило:
 

# Именнованная лакация (правило)     location @modx {          # выполняем подмену на index.php         rewrite ^/(.*)$ /index.php?q=$1 last;     }  

Так как ЧПУ MODX-а построено полностью на реврайтах, а не на реальных файлах, именно благодаря ему все УРЛы и преобразуются в index.php Но это происходит только потому что запрашиваемый файл не найден. Но если файл будет найден, то этого преобразования не будет, а останется реальный УРЛ. И в итоге ключ /index.php не будет соответствовать никогда в этом случае.
 Но это конечно же ситуация исключительная, поэтому конечно ты можешь пренебрегать этим моментом и сделать так, как ты предложил — в 99% случаев оно действительно будет работоспособным. Но у меня свои тараканы в голове и я терпеть не могу неуниверсальность, поэтому у себя оставлю так.

насчет побьется я не совсем уверен, так как неделю назад вообще про nginx не слышал. Но я думаю ты ошибаешся… Пройдись по конфигу nginx и посмотри логику. Я вчера часов 6 с этим конфигом провозился, так что испробовал различные варианты. Смотри вот правило: # Именнованная лакация (правило)     location @modx {          # выполняем подмену на index.php         rewrite ^/(.*)$ /index.php?q=$1 last;     } Так как ЧПУ MODX-а построено полностью на реврайтах, а не на реальных файлах, именно благодаря ему все УРЛы и преобразуются в index.php Но это происходит только потому что запрашиваемый файл не найден. Но если файл будет найден, то этого преобразования не будет, а останется реальный УРЛ. И в итоге ключ /index.php не будет соответствовать никогда в этом случае.
 Но это конечно же ситуация исключительная, поэтому конечно ты можешь пренебрегать этим моментом и сделать так, как ты предложил — в 99% случаев оно действительно будет работоспособным. Но у меня свои тараканы в голове и я терпеть не могу неуниверсальность, поэтому у себя оставлю так.

насчет побьется я не совсем уверен, так как неделю

ну в данном случае у тебя 
 

# устанавливаем ключ-переменную для запроса к мемкешу
set  $memcached_key       "default/$uri?$args";

и все! это же касается только memcached. При чем тут реальные файлы?
 только лишняя переменная=index.php? в ключе

ну в данном случае у тебя # устанавливаем ключ-переменную для запроса к мемкешу
set  $memcached_key       "default/$uri?$args"; и все! это же касается только memcached. При чем тут реальные файлы?
 только лишняя переменная=index.php? в ключе

ну в данном случае у тебя # устанавливаем ключ-пер

При чем тут реальные файлы?

При том, что здесь используется переменная $uri. Как я писал выше, если файл не найден, то УРЛ меняется на /index.php?q=$1 Повторюсь:
 

# Именнованная лакация (правило)
    location @modx { 
        # выполняем подмену на index.php
        rewrite ^/(.*)$ /index.php?q=$1 last;
    }

Так как в большинстве случаев при ЧПУ файлов тупо нет, то постоянно и происходит подмена УРЛа на index.php. При этом и переменная $uri и принимает это значение. А если файл будет найден, то $uri не будет изменена, и будет иметь значение реально запрошенного адреса. Теперь понятно? Плагин конечно я тоже упростил. Изначально он был примерно такой:
 

$query = '/';
            
            $query_str = str_replace('&amp;', '&',($_SERVER['QUERY_STRING']));  
            
            if(!empty($query_vars['q'])){
                $query .= $query_vars['q'];
                unset($query_vars['q']);
            }
            else{
                $query .= 'index.php';
            }
            $query .= "?";
            
            $vars = array();
            foreach($query_vars as $k => $v){
                $vars[] = "{$k}={$v}";
            }
            if($vars){
                $query .= implode("&", $vars);
            }
            $modx->log(1,  print_r($query, 1));
            $modx->cacheManager->set($query , $modx->resource->_output);


И то, что сейчас в плагине осталось — это публичный упрощенный вариант, для которого твои замечания очень обоснованный. Но для меня мой nginx-конфиг более актуальный :-)

При чем тут реальные файлы? При том, что здесь используется переменная $uri. Как я писал выше, если файл не найден, то УРЛ меняется на /index.php?q=$1 Повторюсь: # Именнованная лакация (правило)
    location @modx { 
        # выполняем подмену на index.php
        rewrite ^/(.*)$ /index.php?q=$1 last;
    } Так как в большинстве случаев при ЧПУ файлов тупо нет, то постоянно и происходит подмена УРЛа на index.php. При этом и переменная $uri и принимает это значение. А если файл будет найден, то $uri не будет изменена, и будет иметь значение реально запрошенного адреса. Теперь понятно? Плагин конечно я тоже упростил. Изначально он был примерно такой: $query = '/';
            
            $query_str = str_replace('&amp;', '&',($_SERVER['QUERY_STRING']));  
            
            if(!empty($query_vars['q'])){
                $query .= $query_vars['q'];
                unset($query_vars['q']);
            }
            else{
                $query .= 'index.php';
            }
            $query .= "?";
            
            $vars = array();
            foreach($query_vars as $k => $v){
                $vars[] = "{$k}={$v}";
            }
            if($vars){
                $query .= implode("&", $vars);
            }
            $modx->log(1,  print_r($query, 1));
            $modx->cacheManager->set($query , $modx->resource->_output); И то, что сейчас в плагине осталось — это публичный упрощенный вариант, для которого твои замечания очень обоснованный. Но для меня мой nginx-конфиг более актуальный :-)

При чем тут реальные файлы? При том, что здесь исп

ну так бы сразу и сказал, что у тебя свои замуты)

у меня не замуты, а универсальность :-)

как думаешь, имеет смысл memcached на сокеты перекинуть? По идее еще прирост в скорости должен быть…
 вот эти настройки в обработчике меняю 

('memcached_server', $options, 'localhost:11211')

и по идее будет работать? или тут все сложнее устроено?

как думаешь, имеет смысл memcached на сокеты перекинуть? По идее еще прирост в скорости должен быть…
 вот эти настройки в обработчике меняю ('memcached_server', $options, 'localhost:11211') и по идее будет работать? или тут все сложнее устроено?

как думаешь, имеет смысл memcached на сокеты перек

Честно скажу: сам с сокетами особо не работал. Знаю, что сокеты быстрее всяко, но настройку этого всего не делал.

Честно скажу: сам с сокетами особо не работал. Зна

подскажи как и где переключиться на сокет? пробовал в конфиге прописать как 
 

$config_options = array (
    "cache_handler" => "cache.xPDOMemCached",
    'memcached_server' => 'unix:///var/run/memcached/mem.socket',
    'system_settings_memcached_server' => 'unix:///var/run/memcached/mem.socket',
    'db_memcached_server' => 'unix:///var/run/memcached/mem.socket',

);

не срабатывает нифига!
 хелп!)))

подскажи как и где переключиться на сокет? пробовал в конфиге прописать как $config_options = array (
    "cache_handler" => "cache.xPDOMemCached",
    'memcached_server' => 'unix:///var/run/memcached/mem.socket',
    'system_settings_memcached_server' => 'unix:///var/run/memcached/mem.socket',
    'db_memcached_server' => 'unix:///var/run/memcached/mem.socket',

); не срабатывает нифига!
 хелп!)))

подскажи как и где переключиться на сокет? пробова

подключился, тут тестик небольшой сделал

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

Я же говорил, что с сокетами особо не заморачивалс

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

$memcache->connect('unix:///var/run/memcached/mem.socket', 0)

я пока что локально подключился и тесты провел, чтоб узнать будет ли какая выгода от такого перехода.
 Ты как спец по кешированию подскажи — как перевести всю систему кеширования modx на сокеты теперь? я немного не допонимаю, это именно в файле обработчика кеша нужно сделать? или еще где то нужно пилить?
 по идее нужна только замена $memcache->connect('localhost', 11211) на $memcache->connect('unix:///var/run/memcached/mem.socket', 0) и все должно пахать!

я пока что локально подключился и тесты провел, чт

Так ты в исходники почаще заглядывай. Вот __construct мемкеша:
 

$servers = explode(',', $this->getOption($this->key . '_memcached_server', $options, $this->getOption('memcached_server', $options, 'localhost:11211')));
foreach ($servers as $server) {
    $server = explode(':', $server);
    $this->memcache->addServer($server[0], (integer) $server[1]);
}
$compressThreshold = $this->getOption($this->key . '_memcached_compress_threshold', $options, $this->getOption('memcached_compress_threshold', array(), '20000:0.2'));

То есть укажи в системных настройках memcached_server и должно все заработать. Это именно что касается memcache. И, ксттаи, там же ответ на твои проблемы с компрессией:
 

$compressThreshold = $this->getOption($this->key . '_memcached_compress_threshold', $options, $this->getOption('memcached_compress_threshold', array(), '20000:0.2'));

То же самое и для memcached:
 

$servers = explode(',', $this->getOption($this->key . '_memcached_server', $options, $this->getOption('memcached_server', $options, 'localhost:11211')));

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

$this->memcached->setOption(Memcached::OPT_COMPRESSION, (boolean) $this->getOption($this->key . '_memcached_compression', $options, $this->getOption('memcached_compression', $options, $this->getOption(Memcached::OPT_COMPRESSION, $options, true))));

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

Так ты в исходники почаще заглядывай. Вот __construct мемкеша: $servers = explode(',', $this->getOption($this->key . '_memcached_server', $options, $this->getOption('memcached_server', $options, 'localhost:11211')));
foreach ($servers as $server) {
    $server = explode(':', $server);
    $this->memcache->addServer($server[0], (integer) $server[1]);
}
$compressThreshold = $this->getOption($this->key . '_memcached_compress_threshold', $options, $this->getOption('memcached_compress_threshold', array(), '20000:0.2')); То есть укажи в системных настройках memcached_server и должно все заработать. Это именно что касается memcache. И, ксттаи, там же ответ на твои проблемы с компрессией: $compressThreshold = $this->getOption($this->key . '_memcached_compress_threshold', $options, $this->getOption('memcached_compress_threshold', array(), '20000:0.2')); То же самое и для memcached: $servers = explode(',', $this->getOption($this->key . '_memcached_server', $options, $this->getOption('memcached_server', $options, 'localhost:11211'))); Только вот с компрессией у него лучше дела обстоят, так как он значение берет из системы: $this->memcached->setOption(Memcached::OPT_COMPRESSION, (boolean) $this->getOption($this->key . '_memcached_compression', $options, $this->getOption('memcached_compression', $options, $this->getOption(Memcached::OPT_COMPRESSION, $options, true)))); И, кстати, как я и предполагал, должна быть возможность в принципе отключить для него компрессию.

Так ты в исходники почаще заглядывай. Вот __constr

да компрессия бог с ней… на memcached работает и ладно.
 Исходники я видел, но если прописать туда 

'unix:///var/run/memcached/mem.socket', 0

то не пашет! 
 неужели ты думаешь я сначала не попробовал?))
 выдает ошибку
 

Error caching time of next auto publishing event
Could not cache context settings for mgr.
Could not cache context settings for web.

я в коде не разбираюсь но у меня чувство что explode(':', $server)
 это разбор строки… и если сокет прописывать то и тут надо как то менять…

да компрессия бог с ней… на memcached работает и ладно.
 Исходники я видел, но если прописать туда 'unix:///var/run/memcached/mem.socket', 0 то не пашет! 
 неужели ты думаешь я сначала не попробовал?))
 выдает ошибку Error caching time of next auto publishing event
Could not cache context settings for mgr.
Could not cache context settings for web. я в коде не разбираюсь но у меня чувство что explode(':', $server)
 это разбор строки… и если сокет прописывать то и тут надо как то менять…

да компрессия бог с ней… на memcached работает и л

поэтому нужна твоя помощь!)

Так ты не пиши 'unix:///var/run/memcached/mem.socket', 0
 Это же сразу два параметра. Пиши только unix:///var/run/memcached/mem.socket

Так ты не пиши 'unix:///var/run/memcached/mem.sock

я в коде не разбираюсь но у меня чувство что explode(':', $server)

Да, это разбивка строки.
 Но мне сечас некогда с этим экспериментировать, я пока очень занят.

я в коде не разбираюсь но у меня чувство что explode(':', $server) Да, это разбивка строки.
 Но мне сечас некогда с этим экспериментировать, я пока очень занят.

я в коде не разбираюсь но у меня чувство что explo

да я уже и так и сяк пробовал… Как время будет посмотри

да я уже и так и сяк пробовал… Как время будет пос

а как то можно прописать в обработчике, чтоб он мне логи скинул в журнал чему какая переменная равна?

а как то можно прописать в обработчике, чтоб он мн

Так залезь в код и посмотри что чему равно.

все вроде понял что, к чему… только вот эта строчка непонятна
 

$servers = explode(',', $this->getOption($this->key . '_memcached_server', $options, $this->getOption('memcached_server', $options, 'unix:///var/run/memcached/mem.socket')));


explode разбирает на строки — это ясно.
 getOption — получает параметр по ключу, но их тут сразу несколько одна в одной… вот это мне не совсем ясно…
 $options мы его в данном случае получаем, или наоборот формируем?
 мне кажется все дело в этой строке, так как я пробовал все это убирать и просто делал 
 

$this->memcached->addServer('unix:///var/run/memcached/mem.socket', 0);

но не работает!
 может эти настройки еще где-то в modx торчат?

все вроде понял что, к чему… только вот эта строчка непонятна $servers = explode(',', $this->getOption($this->key . '_memcached_server', $options, $this->getOption('memcached_server', $options, 'unix:///var/run/memcached/mem.socket'))); explode разбирает на строки — это ясно.
 getOption — получает параметр по ключу, но их тут сразу несколько одна в одной… вот это мне не совсем ясно…
 $options мы его в данном случае получаем, или наоборот формируем?
 мне кажется все дело в этой строке, так как я пробовал все это убирать и просто делал $this->memcached->addServer('unix:///var/run/memcached/mem.socket', 0); но не работает!
 может эти настройки еще где-то в modx торчат?

все вроде понял что, к чему… только вот эта строчк

$options — это то, что можно передать в инициализацию объекта. В данном случае вообще на это забей.
 Два раза getOption(), потому что второй раз, это значение по умолчанию. Разбей на два раза, чтобы понятней было.
 

$servers = explode(',', $this->getOption($this->key. '_memcached_server', $options, $this->getOption('memcached_server', $options, 'unix:///var/run/memcached/mem.socket')));
 

$servers_default = $this->getOption('memcached_server', $options, 'unix:///var/run/memcached/mem.socket');

$servers_str = $this->getOption($this->key . '_memcached_server', $options, $servers_default);

$servers = (array)explode(',', $servers_str);


То есть может быть указано несколько серверов. Укажи memcached_server в настройках и все.

$options — это то, что можно передать в инициализацию объекта. В данном случае вообще на это забей.
 Два раза getOption(), потому что второй раз, это значение по умолчанию. Разбей на два раза, чтобы понятней было. $servers = explode(',', $this->getOption($this->key. '_memcached_server', $options, $this->getOption('memcached_server', $options, 'unix:///var/run/memcached/mem.socket'))); Это буквально так: $servers_default = $this->getOption('memcached_server', $options, 'unix:///var/run/memcached/mem.socket');

$servers_str = $this->getOption($this->key . '_memcached_server', $options, $servers_default);

$servers = (array)explode(',', $servers_str); То есть может быть указано несколько серверов. Укажи memcached_server в настройках и все.

$options — это то, что можно передать в инициализа

ну я логически так и додумал, но ошибка все таже — 
 

вот у меня чувство что где то еще — localhost:11211 торчит по умолчанию…

ну я логически так и додумал, но ошибка все таже — Error caching time of next auto publishing event
Could not cache context settings for mgr.
Could not cache context settings for web. вот у меня чувство что где то еще — localhost:11211 торчит по умолчанию…

ну я логически так и додумал, но ошибка все таже —

Вот и ковыряй. Думаешь у меня всегда все сразу получается? Нет, иногда часами сидишь воюешь, а иногда и днями.

Вот и ковыряй. Думаешь у меня всегда все сразу пол

тогда может на $options всетаки нельзя забивать? он ведь у нас в каждой функции идет
 

либо еще какая то фигня мешает работе с сокетами
 либо я хз

тогда может на $options всетаки нельзя забивать? он ведь у нас в каждой функции идет $options= array()) либо еще какая то фигня мешает работе с сокетами
 либо я хз

тогда может на $options всетаки нельзя забивать? о

у меня к тебе одна просьба будет — можешь в своем обработчике закомментировать строчку вот эту
 

сбрось кеш и посмотри какую ошибку выдаст.
 спасибо!

у меня к тебе одна просьба будет — можешь в своем обработчике закомментировать строчку вот эту $this->memcached->setOption(Memcached::OPT_COMPRESSION, (boolean) $this->getOption($this->key . '_memcached_compression', $options, $this->getOption('memcached_compression', $options, $this->getOption(Memcached::OPT_COMPRESSION, $options, true)))); сбрось кеш и посмотри какую ошибку выдаст.
 спасибо!

у меня к тебе одна просьба будет — можешь в своем 

Мне реально сейчас не до этого. Так что будь настоящим джедаем и воюй до последнего сам.

Мне реально сейчас не до этого. Так что будь насто

порадовал)))

все разобрался, все правильно я прописывал, надо было просто чуток подождать. настройки тоже кешировались и мои изменения с кешером не сразу применялись. сейчас все по новой прописал, подождал 5 минут — и все ок! Работает!)

все разобрался, все правильно я прописывал, надо б

и насчет компрессии ты был прав, можно прям в кешере указать, а не лезть в системные настройки-тоже пашет!
 p.s. и может конечно это кажется только, но админка вроде еще шустрее стала!)

и насчет компрессии ты был прав, можно прям в кеше

новый косяк обнаружил. если сайтов несколько, а кеш получается обший, то они в кеше перезаписывают настройки друг друга. Это я имею ввиду не кешированные странички, а именно работу в админке. то есть надо какой то общий ключ вводить для сайта по типу site_name…
 добавить системную настройку cache_prefix и все работает!

новый косяк обнаружил. если сайтов несколько, а ке

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

единственное при очистке кеша — очищается кеш сраз

Вот и славно.

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

Админка будет шустрее работать, так как каждый Aja

Так про cache_prefix вообще забывать не стОит.

Вот это уже точно не скажу.

<?php
switch($modx->event->name){
    case 'OnWebPageComplete': 
        if (!empty($modx->resource) 
            && $modx->resource->get('cacheable') 
            && $modx->resource->get('published') 
            && $modx->resource->_output != ''
            && $_SERVER['REQUEST_METHOD'] == 'GET'
        )
            
        {
            $key = 'index.php?';
            
            $key .= str_replace('&', '&',($_SERVER['QUERY_STRING']));
               
            $modx->log(1, "Key:  '{$key}'");
              
            $modx->cacheManager->set($key , $modx->resource->_output);
        }
        break;
        
    default:;
}


Проверка на GET чтобы если отправили форму не кешировалась страница с ответом.
 

Чтобы ключ был красивее. Modx его все равно модифицирует.
 в
 

$this->key это системная настройка cache_key
 Так что если cache_key = site.com
 Тогда в конфиге nginx пишем
 

set  $memcached_key       "site.com$uri?$args";

<?php
switch($modx->event->name){
    case 'OnWebPageComplete': 
        if (!empty($modx->resource) 
            && $modx->resource->get('cacheable') 
            && $modx->resource->get('published') 
            && $modx->resource->_output != ''
            && $_SERVER['REQUEST_METHOD'] == 'GET'
        )
            
        {
            $key = 'index.php?';
            
            $key .= str_replace('&', '&',($_SERVER['QUERY_STRING']));
               
            $modx->log(1, "Key:  '{$key}'");
              
            $modx->cacheManager->set($key , $modx->resource->_output);
        }
        break;
        
    default:;
} Проверка на GET чтобы если отправили форму не кешировалась страница с ответом. $key = 'index.php?'; Чтобы ключ был красивее. Modx его все равно модифицирует.
 в $this->key . '/' . $key; $this->key это системная настройка cache_key
 Так что если cache_key = site.com
 Тогда в конфиге nginx пишем set  $memcached_key       "site.com$uri?$args";

<?php
switch($modx->event->name){
    case 'OnWebP

Проверка на GET чтобы если отправили форму не кешировалась страница с ответом.

Но это как раз и не стоит делать. Ведь GET — это в том числе и постраничность и прочие моменты, включая гет-поиск. Все, что не должно кешироваться — надо выносить в Ajax.
 

Либо предусматривать какой-то GET-параметр типа nocache=1, чтобы явно указывать, что ее кешировать не надо. Если добавится в запрос этот параметр, для нгинкса это уже будет новый адрес, и он отправит запрос на MODX. MODX не сформирует полный кеш страницы в мемкеш, а значит и нгинкс все время будет отдавать не кешированную страницу.

Проверка на GET чтобы если отправили форму не кешировалась страница с ответом. Но это как раз и не стоит делать. Ведь GET — это в том числе и постраничность и прочие моменты, включая гет-поиск. Все, что не должно кешироваться — надо выносить в Ajax. Либо предусматривать какой-то GET-параметр типа nocache=1, чтобы явно указывать, что ее кешировать не надо. Если добавится в запрос этот параметр, для нгинкса это уже будет новый адрес, и он отправит запрос на MODX. MODX не сформирует полный кеш страницы в мемкеш, а значит и нгинкс все время будет отдавать не кешированную страницу.

Проверка на GET чтобы если отправили форму не кеши

Приветь! 
 Николай настроил по заметкам! html контент работает но в админке вот таки логи ошибок
 

[2016-03-12 15:23:52] (ERROR @ /index.php) Key:  '/index.php?q=news/1453/'
[2016-03-12 15:23:54] (ERROR @ /index.php) Key:  '/index.php?'
[2016-03-12 15:25:26] (ERROR @ /index.php) Key:  '/index.php?'


Приветь! 
 Николай настроил по заметкам! html контент работает но в админке вот таки логи ошибок [2016-03-12 15:23:52] (ERROR @ /index.php) Key:  '/index.php?q=news/1453/'
[2016-03-12 15:23:54] (ERROR @ /index.php) Key:  '/index.php?'
[2016-03-12 15:25:26] (ERROR @ /index.php) Key:  '/index.php?'

Кеширование в Revo

MODX Revolution + nginx + memcached.

Не оправдано большой кеш страниц.

Еще одна фишка с кешированием в Smarty

Кеширование настроек контекстов в MODX Revolution. Я негодую

Еще немного о кешировании в MODX Revolution