RichText

есть готовый кэширующий плагин для ускорения сайта: github modxExtraCachePlugin

умеет кэшировать сессионные ключи от компонентов и прогревать кэш через wget

есть готовый кэширующий плагин для ускорения сайта: github modxExtraCachePlugin умеет кэшировать сессионные ключи от компонентов и прогревать кэш через wget

есть готовый <a href="https://webdevops.ru/blog/ex

Публикуем различные эксперименты и исследования.

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

Система проектов на сайте нашего Клуба

Статистика количества запросов и времени на исполнение в MODX Revolution

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

Summary для MODX Revolution

Передача PropertySet в шаблоны Smarty

Ускорение чанков или новая жизнь старого сайта на modx revo

Гонки на скорость, часть вторая. Ускорение Modx Revo более чем в 8 раз

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

сохранить документ в кеш memcache

Хорошая задумка)

Оно изначально так все задумывалось, просто не все сразу получается внедрить.

Оно изначально так все задумывалось, просто не все

Когда начнем? :)

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

Со следующей недели. На выходных буду программиров

мне вот интересно, а вы такие вещи достаточно быстро пишите? судя по всему как чайка попить)))
 вообще он есть уже yandex.ru/yandsearch?text=modx%20revolution%20summary&clid=1987478&lr=213

мне вот интересно, а вы такие вещи достаточно быст

Ну, топик этот я наверно дольше писал :-)
 Ссылка на поисковик — не очень юзабельно. Надо бы на конкретную страницу отправлять, а то кто знает, что там через несколько дней в результатах будет. Хотя я предполагаю, что имели ввиду класс от Агеля blog.agel-nash.ru/addon/summary.html
 Я как-то на него наткнулся уже после того, как класс переписал. Но в целом там тоже самое почти, то есть тот же переписанный класс из Ditto. Но работает он только с конкретно указанной строковой переменной, а не с массивом ресурса (что в принципе совершенно не критично).

Ну, топик этот я наверно дольше писал :-)
 Ссылка 

Спасибо за отличную заметку!

Потрясающе даже то, что проклятый на днях мною Quip также работает намного быстрее. И весь фокус — в циклах. НЕ В дисковых операциях!
 Стоит знать, что без Quip, но с твоим modxsmarty и с modxtemplate и хорошим phpкешером — сайт становится настоящим сверхсветовым межпланетным двигателем и на довольно слабых серверных ресурсах. 
 

Я тестировал эти штуки на трех разных серверах. От виртуала на 1 ядро/1.7Ghz с 512 мегами, до 8 ядерного железа CoreI7 c 24 гигами памяти (и это УЖЕ явный избыток).

Потрясающе даже то, что проклятый на днях мною Quip также работает намного быстрее. И весь фокус — в циклах. НЕ В дисковых операциях!
 Стоит знать, что без Quip, но с твоим modxsmarty и с modxtemplate и хорошим phpкешером — сайт становится настоящим сверхсветовым межпланетным двигателем и на довольно слабых серверных ресурсах. Я тестировал эти штуки на трех разных серверах. От виртуала на 1 ядро/1.7Ghz с 512 мегами, до 8 ядерного железа CoreI7 c 24 гигами памяти (и это УЖЕ явный избыток).

Потрясающе даже то, что проклятый на днях мною Qui

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

Так а про дисковые операции вообще никто ничего не

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

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

Ну, в этом тоже не поспоришь.

Для перелинковки и для сохранения последовательности. Ссылка на вторую часть: modxclub.ru/blog/sandbox/176.html

Для перелинковки и для сохранения последовательнос

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

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

Проверка же вышеизложенного решения, даже с учетом сетевых задержек по территории Европы, приведена ниже:
 

Resolve time: 27 ms 
 Connect time: 19 ms 
 Download time: 206 ms 
 
 Resolve time: 19 ms 
 Connect time: 9 ms 
 Download time: 67 ms
 
 Resolve time: 297 ms 
 Connect time: 15 ms 
 Download time: 73 ms
 
 Resolve time: 40 ms 
 Connect time: 21 ms 
 Download time: 102 ms

Ссылка, если тоже хотите тут потестить.
 

Средняя скорость 0.43 sec с 26 точек планеты.

Секретная ссылка на службу мониторинга.

Попутно скажу, что для измерения скорости открытия сайта не следует учитывать пинги, хопы и ширину канала и/или работающие фоновые торренты. Для ускорения отклика сайта и уменьшения пинга надо применять другие решения. Проверка же вышеизложенного решения, даже с учетом сетевых задержек по территории Европы, приведена ниже: Resolve time: 27 ms 
 Connect time: 19 ms 
 Download time: 206 ms 
 
 Resolve time: 19 ms 
 Connect time: 9 ms 
 Download time: 67 ms
 
 Resolve time: 297 ms 
 Connect time: 15 ms 
 Download time: 73 ms
 
 Resolve time: 40 ms 
 Connect time: 21 ms 
 Download time: 102 ms Ссылка, если тоже хотите тут потестить. А также вот еще: Средняя скорость 0.43 sec с 26 точек планеты. Секретная ссылка на службу мониторинга.

Попутно скажу, что для измерения скорости открытия

У меня вопрос поводу phpThumbsUp: у MODX появился еще пакет pThumb. Какой все-таки лучше ставить?

У меня вопрос поводу phpThumbsUp: у MODX появился 

Блин, пока пишу основной обстоятельный коммент, попутно ковыряю xFPC. Чел жгет :-)
 

if ((int) $combineJsAndCss == 1) {
	$combineJsAndCss = true;
} else {
	$combineJsAndCss = false;
}

Только сегодня видел картинку «оптимизацией тут и не пахнет»)))

Блин, пока пишу основной обстоятельный коммент, попутно ковыряю xFPC. Чел жгет :-) if ((int) $combineJsAndCss == 1) {
	$combineJsAndCss = true;
} else {
	$combineJsAndCss = false;
} Только сегодня видел картинку «оптимизацией тут и не пахнет»)))

Блин, пока пишу основной обстоятельный коммент, по

Вот здесь подробный обзор: blog.agel-nash.ru/2013/8/thumb.html
 Автор советует по многим причинам именно pThumb ставить. Кстати, он заменяет сниппет phpthumbof, так что на сайте даже сниппеты перебивать не придется.

Вот здесь подробный обзор: blog.agel-nash.ru/2013/

Кстати, реальная его польза в плане кеша у меня вызывает кучу сомнений, но зато в нем есть минификатор CSS и JS, то есть как раз то, о чем я недавно спрашивал. На досуге покопаю. Спасибо за наводку!

Кстати, реальная его польза в плане кеша у меня вы

Итак, дописал основной коммент :-)
 

Спасибо за собирательный топик!
 А я дам несколько комментариев-уточнений.
 

а) Открываем сниппет phpThumbOF(OF!!) и вставляем внутрь(!) его КОД сниппета phpThumbsUp. Убили много зайцев сразу и не надо ковырять сотню чанков. Минусы не стоят того, чтобы заботиться о них.

Я бы вот так не стал делать. В среднестатистическом сайте не так много вызовов этого сниппета по шаблонам и чанкам, чтобы убивать обновления и т.п. Хотя если посмотреть на то, как pThumb устанавливает с обновлением сниппет phpthumbof, то тут уже многое становится не однозначным.
 

<?php $output = $modx->smarty->fetch('header.tpl'); $output .= $modx->smarty->fetch('inside.tpl'); $output .= $modx->smarty->fetch('footer.tpl'); return $output;

 

Я бы все-таки не стал вызывать 3 шаблона таким образом, а сделал бы один общий шаблон, и при необходимости сделал в нем инклюды {include file=«header.tpl»} и т.п., тем более что в таком случае можно использовать локальное кеширование подшаблона, а в случае с приведенным примером этого сделать нельзя (если только не включено глобальное кеширование Smarty).
 

а) Этой копии ставим тип ресурса «Документ с PHP-шаблоном» (проверено, так быстрее).

Вот это утверждение очень сомнительное. Я оставил CRC phpTemplateResource так, на всякий случай (так сказать, остался в наследство). Но в силу особенностей его развития, он в итоге деградировал и оказался менее функциональным, чем его предок. Дело в том, что в нем исключено кеширование шаблона. То есть при любом раскладе его шаблон будет вызываться и выполняться, в то время, как нативный класс не выполняет шаблон, если он закеширован уже и у него не стоит phptemplates.non-cached=true. Так что родной класс, если уже отработан и закеширован, а методе process() сразу вернет конечный код, а phpTemplateResource в любом случае выполнит шаблон, и это никак не может быть быстрее. 
 К тому же, как практика показала, создавать именно «Документ с php-шаблоном», а не просто документ — бонально неудобно.
 

Например:
 {link id="55"}

 выглядит правильно, но если он обрамлён еще в одни кавычки вот так:
 a href="{link id="55"}"

 то нифига не заработает. 
 

Неверное утверждение. Смарти парсит все внутри фигурных скобок, и ему пофиг что за пределами этих скобок. Он спарсит {link id=«55»} и заменит на его значение, и все будет ОК. К слову, если пробелов нет, то можно вообще без ковычек, к примеру {link id=55}.
 Вот еще пример того, как можно вызывать вместе с ковычками:
 

И с этим нет никаких проблем.
 Резюме: конечно, ошибок вижу много. Но не это главное! Главное то, что ты смог значительно ускорить свой сайт. И быть может далеко не всем поможет этот топик (то есть не будет исчерпывающим руководством), но он точно будет примером того, что при желании можно ускорить свой Рево-сайт очень значительно. Спасибо!

Итак, дописал основной коммент :-) Спасибо за собирательный топик!
 А я дам несколько комментариев-уточнений. а) Открываем сниппет phpThumbOF(OF!!) и вставляем внутрь(!) его КОД сниппета phpThumbsUp. Убили много зайцев сразу и не надо ковырять сотню чанков. Минусы не стоят того, чтобы заботиться о них. Я бы вот так не стал делать. В среднестатистическом сайте не так много вызовов этого сниппета по шаблонам и чанкам, чтобы убивать обновления и т.п. Хотя если посмотреть на то, как pThumb устанавливает с обновлением сниппет phpthumbof, то тут уже многое становится не однозначным. <?php $output = $modx->smarty->fetch('header.tpl'); $output .= $modx->smarty->fetch('inside.tpl'); $output .= $modx->smarty->fetch('footer.tpl'); return $output; Я бы все-таки не стал вызывать 3 шаблона таким образом, а сделал бы один общий шаблон, и при необходимости сделал в нем инклюды {include file=«header.tpl»} и т.п., тем более что в таком случае можно использовать локальное кеширование подшаблона, а в случае с приведенным примером этого сделать нельзя (если только не включено глобальное кеширование Smarty). а) Этой копии ставим тип ресурса «Документ с PHP-шаблоном» (проверено, так быстрее). Вот это утверждение очень сомнительное. Я оставил CRC phpTemplateResource так, на всякий случай (так сказать, остался в наследство). Но в силу особенностей его развития, он в итоге деградировал и оказался менее функциональным, чем его предок. Дело в том, что в нем исключено кеширование шаблона. То есть при любом раскладе его шаблон будет вызываться и выполняться, в то время, как нативный класс не выполняет шаблон, если он закеширован уже и у него не стоит phptemplates.non-cached=true. Так что родной класс, если уже отработан и закеширован, а методе process() сразу вернет конечный код, а phpTemplateResource в любом случае выполнит шаблон, и это никак не может быть быстрее. 
 К тому же, как практика показала, создавать именно «Документ с php-шаблоном», а не просто документ — бонально неудобно. Например:
 {link id="55"}

 выглядит правильно, но если он обрамлён еще в одни кавычки вот так:
 a href="{link id="55"}"

 то нифига не заработает. Неверное утверждение. Смарти парсит все внутри фигурных скобок, и ему пофиг что за пределами этих скобок. Он спарсит {link id=«55»} и заменит на его значение, и все будет ОК. К слову, если пробелов нет, то можно вообще без ковычек, к примеру {link id=55}.
 Вот еще пример того, как можно вызывать вместе с ковычками: <img src="{snippet name="phpthumbof" params="input=`{$object.image}`&options=`h=130&w=200`"}" /> И с этим нет никаких проблем.
 Резюме: конечно, ошибок вижу много. Но не это главное! Главное то, что ты смог значительно ускорить свой сайт. И быть может далеко не всем поможет этот топик (то есть не будет исчерпывающим руководством), но он точно будет примером того, что при желании можно ускорить свой Рево-сайт очень значительно. Спасибо!

Итак, дописал основной коммент :-) Спасибо за соби

Спасибо за отзыв и информацию.

Извиняюсь! Как-то пропустил топик…
 

По поводу наборов параметров в чанках и сниппетах: как я говорил ранее, это и сейчас имеется. То есть просто вызываем {snippet name=«mysnippet@propset1@propset2@...»} или {chunk name=«mychunk@propset1@propset2@...»}.
 А вот в процессорах этого действительно изначально нет. То есть вообще изначально сам MODX не предусматривал вызова процессоров с наборами параметров.
 Буду вносить этот функционал в modxSmarty. Создал себе тикет.

Извиняюсь! Как-то пропустил топик… По поводу наборов параметров в чанках и сниппетах: как я говорил ранее, это и сейчас имеется. То есть просто вызываем {snippet name=«mysnippet@propset1@propset2@...»} или {chunk name=«mychunk@propset1@propset2@...»}.
 А вот в процессорах этого действительно изначально нет. То есть вообще изначально сам MODX не предусматривал вызова процессоров с наборами параметров.
 Буду вносить этот функционал в modxSmarty. Создал себе тикет.

Извиняюсь! Как-то пропустил топик… По поводу набор

Смотрю за тобой уже давно и смотрю сколько полезных и интересных статей написал)
 Сам делаю сайты на 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. будет ли обратная поддержка старых сайтов (то есть обновление убьет сайт и его придется переписывать) 
 ?

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

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

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

прочел, поставил 5.4.17 — да скорость хорошая! 
 сейчас ради прикола воткнул вот эту:
 PHP 5.4.9-4ubuntu2.2 (cli) (built: Jul 15 2013 18:24:39) 
 Copyright © 1997-2012 The PHP Group
 Zend Engine v2.4.0, Copyright © 1998-2012 Zend Technologies
 

ну и как бы скорость та же самая — все быстро как и раньше!)

прочел, поставил 5.4.17 — да скорость хорошая! 
 сейчас ради прикола воткнул вот эту:
 PHP 5.4.9-4ubuntu2.2 (cli) (built: Jul 15 2013 18:24:39) 
 Copyright © 1997-2012 The PHP Group
 Zend Engine v2.4.0, Copyright © 1998-2012 Zend Technologies ну и как бы скорость та же самая — все быстро как и раньше!)

прочел, поставил 5.4.17 — да скорость хорошая! 
 с

Это «ускорение» появилось в версии 5.4, поэтому теоретически должно работать с 5.4.x и до скончания веков. Однако в версии 5.5, похоже, опять производительность несколько падает, вероятно потому, что 5.5 я ставил на Debian 6, вместо предназначенного Debian 7. Но это уже не важно.

Это «ускорение» появилось в версии 5.4, поэтому те

Возможно вы мне подскажете, уже три дня мучает вопроc:
 проделываю следующую штуку — вызываю пустую страницу с шаблоном blank некешируемую
 1й вызов — 0.1 секунда, 2й и следующие (60с)- 0.04секунды
 это шаред на timeweb.
 

проделываю тот же фокус на vps 
 1й вызов — 0.08 секунда, 2й и следующие — 0.08секунды
 

вопрос — что так на шареде кеширует вызов? ведь страничка то некешируемая, но код каким то образом кешируется и отдается очень быстро!
 на vps пробовал ставил различные акселераторы, но такого эффекта добиться не смог!
 

будьте добры подскажите в чем дело. Мне это покоя не дает)

Возможно вы мне подскажете, уже три дня мучает вопроc:
 проделываю следующую штуку — вызываю пустую страницу с шаблоном blank некешируемую
 1й вызов — 0.1 секунда, 2й и следующие (60с)- 0.04секунды
 это шаред на timeweb. проделываю тот же фокус на vps 
 1й вызов — 0.08 секунда, 2й и следующие — 0.08секунды вопрос — что так на шареде кеширует вызов? ведь страничка то некешируемая, но код каким то образом кешируется и отдается очень быстро!
 на vps пробовал ставил различные акселераторы, но такого эффекта добиться не смог! будьте добры подскажите в чем дело. Мне это покоя не дает)

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

Добавил параметр endTags.

Немного вклинюсь: не забывайте, что MODX по умолчанию в БД хранит сессии. А на уровне мускула тоже есть кеширование. Может на шареде кеш мускула более продолжительный выставлен.
 Второе: VPS-ка — это виртуальная урезанная штука только со своими ресурсами (хотя Ден рассказывал про несколько вариантов виртуализации). А у шареда ресурсы общие, при этом это очень внушительные ресурсы, и если никакой сайт не напрягает серьезно сервер, то он в состоянии выдавать очень большие производственные показатели. Расчет же на то, что не будет длительных нагрузок в единицу времени. Так что многие задачи на таймвебе всегда выполнялись быстрее, чем на любом облачном хосте, с которым мне приходилось иметь дело.

Немного вклинюсь: не забывайте, что MODX по умолча

ну быстрый результат только в течении определенного времени действует… так что это полюбому кеш… 
 а вот про мускул то я не подумал...) возможно дело действительно в нем. Нужно будет проверить… спасибо за наводку!

ну быстрый результат только в течении определенног

не за что.

пробовал кеширование mysql, оно не дало такой прирост обработки(((
 есди 

mysql> show global status like 'Qcache%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 14       |
| Qcache_free_memory      | 16535408 |
| Qcache_hits             | 1696     |
| Qcache_inserts          | 195      |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 1        |
| Qcache_queries_in_cache | 115      |
| Qcache_total_blocks     | 280      |
+-------------------------+----------+


как понять эффективен кеш или нет?

пробовал кеширование mysql, оно не дало такой прирост обработки(((
 есди mysql> show global status like 'Qcache%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 14       |
| Qcache_free_memory      | 16535408 |
| Qcache_hits             | 1696     |
| Qcache_inserts          | 195      |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 1        |
| Qcache_queries_in_cache | 115      |
| Qcache_total_blocks     | 280      |
+-------------------------+----------+ как понять эффективен кеш или нет?

пробовал кеширование mysql, оно не дало такой прир

С этим не подскажу, это уже тонкости настройки.

ну и вот первый вопрос )
 как получить страничку в html после обработки парсером всех чанков и других тегов… и затем сохранить ее в переменную?

ну и вот первый вопрос )
 как получить страничку в

$output = &$modx->resource->_output;
$time = time();
$cacheArray = array('output'=>$output, 'time'=>$time);
$tmp_object = $output;

$output = &$modx->resource->_output;
$time = time(

да и насчет OnBeforeSaveWebPageCache неправильно думаю, оно срабатывает только когда ресурс сохраняем… какое событие сюда лучше подойдет?

да и насчет OnBeforeSaveWebPageCache неправильно д

не чет не то…

А зачем отдельная инициализация мемкеша? Он же в составе MODX-а идет. По умолчанию в настройках MODX-а указано cache_handler=xPDOFileCache, то есть используется файловый кеш-провайдер. Поменяй на cache.xPDOMemCached и все. Кеширование будет на мемкеше. И в плагине спокойно сможешь использовать $modx->cacheManager->set($key, $value); Плюс к этому при сбросе кеша сайта MODX и твой пользовательский кеш будет очищать, не надо ничего дописывать.

А зачем отдельная инициализация мемкеша? Он же в с

А что тебя не устраивает? Наоборот правильное событие. Если документ кешируемый и не был еще закеширован, тогда этот плагин и сработает. А если уже закеширован, то у тебя nginx будет отдавать страницу и все.

А что тебя не устраивает? Наоборот правильное собы

Пожалуй, я тоже сейчас попробую это сделать, давно хотел.

Пожалуй, я тоже сейчас попробую это сделать, давно

Кстати, имей ввиду, что еще в мемкеш можно объекты сохранять. Только там есть тонкости. Нельзя туда сохранить, к примеру, дескриптор соединения с базой данных. Есть в общем ООП-шные методы __sleep() и __wakeup(). __sleep() сработает прям перед сохранением (автоматически). В нем можно будет удалить переменные $modx и т.п., а __wakeup() сработает автоматически, когда будешь получать объект из кеша (в этот момент ему можно будет опять присвоить $modx). Тоже может пригодиться для тюннинга.

Кстати, имей ввиду, что еще в мемкеш можно объекты

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

да я пока на файловый перешел, чтоб только плагин 

Кстати, ты memcache ведь используешь? А почему не memcached? 
 Вот сравнительная статья.

Кстати, ты memcache ведь используешь? А почему не 

ну событие сработает один раз когда документ сохраняем, потом из memcache кеш уйдет и тю тю… кеша нет

ну событие сработает один раз когда документ сохра

Поменяй на xPDOMemCached и все.

Поправочка — cache.xPDOMemCached
 

И еще момент: чтобы сразу есть настройки, которые необходимо и в сам конфиг-файл переносить. Дело в том, что для чтения системных настроек из базы данных требуется инициализация самого MODX-а. Это звучит очень логично, но не все на этом внимание заостряют. Так вот, инициализация требует предварительного чтения конфигов. И вот что получается — пока MODX не получил данные из базы данных, он использует конфиги файловые, в том числе и значения по умолчанию. А так как настройка cache_handler=cache.xPDOMemCached хранится в базе данных, то в момент инициализации MODX еще ничего о ней не знает, и соответственно использует стандартный файловый кеш-провайдер. И получив настройки из БД, он только потом очухивается, и начинает использовать Memcached. Но до этого успевает записать конфиги в файлы, и вообще каждый раз при старте читает конфиги из файлов.
 

Вот чтобы этого не происходило и чтобы он сразу использовал Memcached, зайди в core/config/config.inc.php и в $config_options пропиши эту настройку тоже:
 

$config_options = array (
    "cache_handler" => "cache.xPDOMemCached",
);

Вот тогда он сразу будет мемкешед юзать.

Поменяй на xPDOMemCached и все. Поправочка — cache.xPDOMemCached И еще момент: чтобы сразу есть настройки, которые необходимо и в сам конфиг-файл переносить. Дело в том, что для чтения системных настроек из базы данных требуется инициализация самого MODX-а. Это звучит очень логично, но не все на этом внимание заостряют. Так вот, инициализация требует предварительного чтения конфигов. И вот что получается — пока MODX не получил данные из базы данных, он использует конфиги файловые, в том числе и значения по умолчанию. А так как настройка cache_handler=cache.xPDOMemCached хранится в базе данных, то в момент инициализации MODX еще ничего о ней не знает, и соответственно использует стандартный файловый кеш-провайдер. И получив настройки из БД, он только потом очухивается, и начинает использовать Memcached. Но до этого успевает записать конфиги в файлы, и вообще каждый раз при старте читает конфиги из файлов. Вот чтобы этого не происходило и чтобы он сразу использовал Memcached, зайди в core/config/config.inc.php и в $config_options пропиши эту настройку тоже: $config_options = array (
    "cache_handler" => "cache.xPDOMemCached",
); Вот тогда он сразу будет мемкешед юзать.

Поменяй на xPDOMemCached и все. Поправочка — cache

незнаю, изначально как то только memcache на сервер ставил…

незнаю, изначально как то только memcache на серве

наверно лучше на OnWebPagePrerender — тогда кеш умер, страничку обновили и кеш снова есть

наверно лучше на OnWebPagePrerender — тогда кеш ум

Ставь memcached. Не сложнее устанавливается. Конфиги его будут в /etc/memcached.conf (это если лимит памяти захочешь поднять).

Ставь memcached. Не сложнее устанавливается. Конфи

Тоже логично. Хотя можно и мемкешу, и MODX-у задать одинаковое время жизни кеша. Тогда будет нормуль.

Тоже логично. Хотя можно и мемкешу, и MODX-у задат

так ты мне обьясни в чем разница то? я вот пока не вижу разницы, так зачем на него переходить.
 что cache.xPDOMemCached, что cache.xPDOMemCache — по сути одно и тоже, разъве нет?

так ты мне обьясни в чем разница то? я вот пока не

как обработанную страничку в кеш запихать в виде html? у меня что то пока не выходит…

как обработанную страничку в кеш запихать в виде h

значит как почистить чеш можно не волноваться, при OnSiteRefresh само все почистится, это уже хорошо)

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

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

Я же тебе выше дал ссылку на сравнительную статью.

Щас сделаю и скажу.

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

ну я для себя сделал выводы что разницы никакой)
 

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

public function _postProcess() {
    if ($this->resourceGenerated && $this->getOption('cache_resource', null, true)) {
        if (is_object($this->resource) && $this->resource instanceof modResource && $this->resource->get('id') && $this->resource->get('cacheable')) {
            $this->invokeEvent('OnBeforeSaveWebPageCache');
            $this->cacheManager->generateResource($this->resource);
        }
    }
    $this->invokeEvent('OnWebPageComplete');
}

Черновой код плагина:
 

<?php
switch($modx->event->name){
    case 'OnWebPageComplete':
        $key = "resource/".$modx->resourceIdentifier; 
        $output = & $modx->resource->_output;
        $modx->cacheManager->set($key, $output);
        break;
        
    default:;
}

Но сейчас еще буду проверять насколько этот кеш годится. Ведь там php return. Скорее всего надо будет переопределять кеш-провайдер, чтобы сохранять чистый HTML.

В таком случае наверно лучше использовать OnWebPageComplete. Это самое последнее событие, и как видишь, без учета закеширован или нет. public function _postProcess() {
    if ($this->resourceGenerated && $this->getOption('cache_resource', null, true)) {
        if (is_object($this->resource) && $this->resource instanceof modResource && $this->resource->get('id') && $this->resource->get('cacheable')) {
            $this->invokeEvent('OnBeforeSaveWebPageCache');
            $this->cacheManager->generateResource($this->resource);
        }
    }
    $this->invokeEvent('OnWebPageComplete');
} Черновой код плагина: <?php
switch($modx->event->name){
    case 'OnWebPageComplete':
        $key = "resource/".$modx->resourceIdentifier; 
        $output = & $modx->resource->_output;
        $modx->cacheManager->set($key, $output);
        break;
        
    default:;
} Но сейчас еще буду проверять насколько этот кеш годится. Ведь там php return. Скорее всего надо будет переопределять кеш-провайдер, чтобы сохранять чистый HTML.

В таком случае наверно лучше использовать OnWebPag

так не пойдет, ты стандартно его засунул… тогда можно было вообще плагин не писать, а просто обработчик переключить на cache.xPDOMemCached, и уже nginx выбирать что modx стандартно кеширует!

так не пойдет, ты стандартно его засунул… тогда мо

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

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

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

Нафига такой изврат? Зачем данные туда-сюда гонять?
 

Переопределять — это создать свой кеш-провайдер, расширяющий базовый, и туда добавить, к примеру, метод setPureCode() то есть сохранять как есть, а не совать в return;

обработчик менять на файловый, получать страничку и запихивать уже в memcache Нафига такой изврат? Зачем данные туда-сюда гонять? Переопределять — это создать свой кеш-провайдер, расширяющий базовый, и туда добавить, к примеру, метод setPureCode() то есть сохранять как есть, а не совать в return;

обработчик менять на файловый, получать страничку 

и уже nginx выбирать что modx стандартно кеширует!

1. Стандартный кеш документа нафиг не нужен, потому что там много хлама.
 2. Нгинкс не обрабатывает php.

и уже nginx выбирать что modx стандартно кеширует! 1. Стандартный кеш документа нафиг не нужен, потому что там много хлама.
 2. Нгинкс не обрабатывает php.

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

ну все что ты сказал правильно, и я это вполне пон

Ты сможешь это сделать?

Судя по всему, ничего переопределять не понадобится. Я уже результат получил на уровне нгинкса. Сейчас последние штрихи в плагине делаю. Больше с правилами для нгинкса провозился, я же не сисадмин.

Судя по всему, ничего переопределять не понадобитс

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

Ну все, я получил результат конечный. Было несколь

Ок!) С нетерпением жду…
 Молодчик!

Пока топик пишу, погоняй: evropa-clinic.modxdev.webtm.ru
 Смотри в файрбаге время отклика при повторном заходе.

Пока топик пишу, погоняй: evropa-clinic.modxdev.we

ну нормал 100 мс...)))
 ты только время кеша маленькое выставил… или еще делаешь что то…
 как интерпрайз летает)))

ну нормал 100 мс...)))
 ты только время кеша мален

На самом деле меньше. У меня 70+- несколько мсек показывает. Из них минимум 40 — это пинг :-)
 

ты только время кеша маленькое выставил… или еще делаешь что то…

Вообще-то когда ты смотрел, лоэдимпакт в 50 клиентов фигачил по сайту)))

ну нормал 100 мс...))) На самом деле меньше. У меня 70+- несколько мсек показывает. Из них минимум 40 — это пинг :-) ты только время кеша маленькое выставил… или еще делаешь что то… Вообще-то когда ты смотрел, лоэдимпакт в 50 клиентов фигачил по сайту)))