RichText

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

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

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

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

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

Большой магазин на MODX Revolution.

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

Tips & tricks

Blog by Fi1osof

Список modxSmarty тегов

Вызов вложенных сниппетов с передачей параметров.

Самый простой кросс-контекстный роутер

[Решено] Большая нагрузка phpThumb на сервер при большом количестве картинок

Обзор компонентов под MODX Revoluton для обработки изображений на лету

5 причин отказаться от адаптивного дизайна

Большой интернет-магазин на MODX Revolution. 150 000+ товаров. Часть первая.

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

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

$resource->uri вместо [[~[[*id]] ]];

не в тему, но касается парсера тоже.
 тот же quip, например, вообще еще никем не был заменен (всякого рода modxtalks и tickets не рассматриваю), но тормозит систему так дико, что лучше его даже старый добрый тормозной phpthumbof работающий вообще даже с графикой.
 подебажив quip немного видно, что там сплошняком парсер с тегами работает и именно это вызывает дикие тормоза (как, впрочем, и везде в modx). Даже такая фигня как выдача формы «quipreply» нагружает систему похлеще getresources.
 

отсюда вопрос, может парсер новый написать будет проще? не?

не в тему, но касается парсера тоже.
 тот же quip, например, вообще еще никем не был заменен (всякого рода modxtalks и tickets не рассматриваю), но тормозит систему так дико, что лучше его даже старый добрый тормозной phpthumbof работающий вообще даже с графикой.
 подебажив quip немного видно, что там сплошняком парсер с тегами работает и именно это вызывает дикие тормоза (как, впрочем, и везде в modx). Даже такая фигня как выдача формы «quipreply» нагружает систему похлеще getresources. отсюда вопрос, может парсер новый написать будет проще? не?

не в тему, но касается парсера тоже.
 тот же quip,

тот же quip, например, вообще еще никем не был заменен

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

Ну вот мы используем Smarty и радуемся. А замена родного парсера в MODX-е (полное его обновление) обсуждается. Не исключено, что не пройдет и года, и он появится.

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

тот же quip, например, вообще еще никем не был зам

ну тогда выдыхаем.

Хм. По-моему когда 150 тысяч + товаров, тогда уже вопросы к покупке собственного датацентра могут отправляться…

Хм. По-моему когда 150 тысяч + товаров, тогда уже 

А зачем? Практика показывает, что можно на небольшом выделенном сервере работать (сейчас я на modxcloud.com как обычно работаю, но уверен, боевую работу запросто обеспечит недорогой сервер с мемкешем или APC).

А зачем? Практика показывает, что можно на небольш

ну у меня отношение давно проще на этот счет. если можно замутить дата-центр, то так интересней, чем пытаться вжать супермаркет для мегаполиса в 96 мегабайт памяти и 1 жидкое ядро. =)

ну у меня отношение давно проще на этот счет. если

Ну вот смотри: на самом деле десятки и сотни тысяч товаров — это не супермного. Датацентр и т.п. — это все большие дальнейшие издержки. В год может капать тысячи долларов только на хостинг. А здесь сел, нормально все оптимизировал, и сидишь на modxcloud.com за $10 (если не выгонят :-) ).

Ну вот смотри: на самом деле десятки и сотни тысяч

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

Я это к тому, что никогда не лишнее оптимизировать

Как бы я не прикалывался, а оптимизация — вещь полезная, согласен. И будет полезной. И одно другому не мешает =)

Как бы я не прикалывался, а оптимизация — вещь пол

Истинно.

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

Жаль только большинство заказчиков это вряд ли пой

Да, не ценят. Те же хамстеры сколько сидели на своем неработающем магазине? Больше года?

Да, не ценят. Те же хамстеры сколько сидели на сво

да там жесть вообще, наверное где то так

Но ведь проблема не только в них, а еще и в том, что им просто не могли это сделать те программисты, которые занимались их магазином. Так что здесь вина не только на совести заказчика.

Но ведь проблема не только в них, а еще и в том, ч

Я это просто к тому, что все это очень не однозначно. Нет четких критериев оценки крутости и стоимости разработки. Один школьник может запросить 100 000, просто потому что он будет 3 месяца этим заниматься (в то время, как профи сделает за пару дней). В свою очередь заказчик может не знать как это реально оценить, и не понимает, почему профи надо платить так много.
 Это вон в спорте все понятно — пробежал на пол-секунды стометровку быстрее других — самый крутой, на тебе золотую медаль!

Я это просто к тому, что все это очень не однознач

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

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

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

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

О, да да да, медленные чанки и парсер.
 Похвастаюсь и тут, что я накопал. Как укорить работу парсера modx revo? Ответ просще, чем кажется.
 modxclub.ru/blog/sandbox/175.html
 

Что интересно, для многих проектов этого решения может хватить с головой!

О, да да да, медленные чанки и парсер.
 Похвастаюсь и тут, что я накопал. Как укорить работу парсера modx revo? Ответ просще, чем кажется.
 modxclub.ru/blog/sandbox/175.html Что интересно, для многих проектов этого решения может хватить с головой!

О, да да да, медленные чанки и парсер.
 Похвастаюс

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

Я делал сайт для настольных и попутно добавлял мобильную версию. Еще со временем WAP'a так делал.
 Адаптивные дизайны смело решают эту проблему с перевесом где-то 75% за настольный и 25% за мобильный.
 Лично меня такой расклад устраивает, так как многие люди по сайту еще пока лазают и ищут что-то. 
 НО! если речь идёт о мобильных, то лучше сразу делать «я не сайт — я приложение», где юзеру выдается решение прямо в глаза, и ТОЛЬКО решение, без особой графики, без рекламы и прочего лишнего говна.
 

То есть мой подход был бы таким: ПЕРВЫМ ИДЁТ ИСКОМОЕ ЮЗЕРОМ РЕШЕНИЕ. Затем всё остальное.
 

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

Однако будущее точно вот за этим: быстрая и точная доставка решения конечному пользователю без промежуточных кликов (и форумы, кстати, тоже по этой причине будут медленно, но верно, вымирать).
 

Так что вот так я вижу будущее, примерно на полтора-три года вперед.

Я делал сайт для настольных и попутно добавлял мобильную версию. Еще со временем WAP'a так делал.
 Адаптивные дизайны смело решают эту проблему с перевесом где-то 75% за настольный и 25% за мобильный.
 Лично меня такой расклад устраивает, так как многие люди по сайту еще пока лазают и ищут что-то. 
 НО! если речь идёт о мобильных, то лучше сразу делать «я не сайт — я приложение», где юзеру выдается решение прямо в глаза, и ТОЛЬКО решение, без особой графики, без рекламы и прочего лишнего говна. То есть мой подход был бы таким: ПЕРВЫМ ИДЁТ ИСКОМОЕ ЮЗЕРОМ РЕШЕНИЕ. Затем всё остальное. Что забавно, что против упомянутого мной подхода будут дико возражать блогеры и все кто монетизирует сайты на рекламе. Однако будущее точно вот за этим: быстрая и точная доставка решения конечному пользователю без промежуточных кликов (и форумы, кстати, тоже по этой причине будут медленно, но верно, вымирать). Так что вот так я вижу будущее, примерно на полтора-три года вперед.

Я делал сайт для настольных и попутно добавлял моб

Ну, пройдет 1,5-3 года, и посмотрим :-)

Потрясающе даже то, что проклятый на днях мною 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-ем.

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

Так не, я точно не собираюсь в этом плане спорить.

Твое решение конечно же ускоряет работу (верю на слово), но ведь одно другому не мешает. Зачем лишнюю работу создавать там, где это не требуется?

Твое решение конечно же ускоряет работу (верю на с

Оба решения верны. 
 Обновление же PHP, о чем врядли кто-то даже подозревал, сильно поможет всем, кто еще не дорос до твоего уровня и копается в чанках, тегах, и супер-вложенных завихрениях. Это факт, могу за себя даже сказать, все с этого начинают.
 

Решение с обходом парсера вообще — само по себе бомба. Но НЕ ВСЕМ оно будет по зубам. 
 

Так что тут просто два решения, и оба верны.

Оба решения верны. 
 Обновление же PHP, о чем врядли кто-то даже подозревал, сильно поможет всем, кто еще не дорос до твоего уровня и копается в чанках, тегах, и супер-вложенных завихрениях. Это факт, могу за себя даже сказать, все с этого начинают. Решение с обходом парсера вообще — само по себе бомба. Но НЕ ВСЕМ оно будет по зубам. Так что тут просто два решения, и оба верны.

Оба решения верны. 
 Обновление же PHP, о чем вряд

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

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

И хорошо их делать оба :-)

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

О! 
 Для версии сайта для анонимусов еще третье надо сделать, а именно:
 

(ссылка, запасная) 
 и будет полный атас, почти как гугл.

О! 
 Для версии сайта для анонимусов еще третье надо сделать, а именно: Установить xFPC (ссылка, запасная) 
 и будет полный атас, почти как гугл.

О! 
 Для версии сайта для анонимусов еще третье на

Замутил! modxclub.ru/blog/sandbox/176.html

Для перелинковки и для сохранения последовательности. Ссылка на вторую часть: 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`"}" /> И с этим нет никаких проблем.
 Резюме: конечно, ошибок вижу много. Но не это главное! Главное то, что ты смог значительно ускорить свой сайт. И быть может далеко не всем поможет этот топик (то есть не будет исчерпывающим руководством), но он точно будет примером того, что при желании можно ускорить свой Рево-сайт очень значительно. Спасибо!

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

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

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

Интересная статья, на самом деле, для мобильников 

Да, я согласен. Это мне вот нужен просто технический интерфейс для доступа к желаемой информации. А у кого-то совершенно другое восприятие. Ему картинки нужны, привычное расположение блоков и т.п.

Да, я согласен. Это мне вот нужен просто техническ

1. Зачем случайное число и куча рекурсивных проходов вверх по дереву, если пары alias+id (который unique primary key)и проверки по одному полю в таблице с индексом в нужном месте вполне хватило бы закрыть эту проблему.
 2. Кроме времени еще важна и память. На клауде можно не боятся, но на хостинге процесс могут затоптать за оверхед по памяти. 5000 тыс конечно не число, но я бы предусмотрел бы какое-нибудь порционное скармливание данных по чуть-чуть. Не знаю наверняка, но скорее всего так оно и есть. Печально, если нет :) Ну и запускать такое нужно не через веб-морду. В консоли ограничений на выполнение php точно нет.
 3. Это скорее болезнь самого modx и его системы кеширования. Особо не придумать ничего. Разве то итемы каталога держать не в ресурсах
 4. Стандартные решения удобны тем, что просты и понятны. Но на таких объемах я бы подумал о подключении какого-нибудь sphinx или провел бы серьезную денормализацию данных и возможно что-то положил бы в какой-нибудь redis или mongo или что там сейчас можно.
 

P.S. Ответы пишу не с пустой головы. Работаю сейчас с проектом, у которого под миллион уников в сутки и отдельные таблицы весят под 10 гб, не считая десятков миллионов записей в nosql-хранилищах. Это все добро конечно же не на modx, но подходы в крупных проектах все равно одни и те же.

1. Зачем случайное число и куча рекурсивных проходов вверх по дереву, если пары alias+id (который unique primary key)и проверки по одному полю в таблице с индексом в нужном месте вполне хватило бы закрыть эту проблему.
 2. Кроме времени еще важна и память. На клауде можно не боятся, но на хостинге процесс могут затоптать за оверхед по памяти. 5000 тыс конечно не число, но я бы предусмотрел бы какое-нибудь порционное скармливание данных по чуть-чуть. Не знаю наверняка, но скорее всего так оно и есть. Печально, если нет :) Ну и запускать такое нужно не через веб-морду. В консоли ограничений на выполнение php точно нет.
 3. Это скорее болезнь самого modx и его системы кеширования. Особо не придумать ничего. Разве то итемы каталога держать не в ресурсах
 4. Стандартные решения удобны тем, что просты и понятны. Но на таких объемах я бы подумал о подключении какого-нибудь sphinx или провел бы серьезную денормализацию данных и возможно что-то положил бы в какой-нибудь redis или mongo или что там сейчас можно. P.S. Ответы пишу не с пустой головы. Работаю сейчас с проектом, у которого под миллион уников в сутки и отдельные таблицы весят под 10 гб, не считая десятков миллионов записей в nosql-хранилищах. Это все добро конечно же не на modx, но подходы в крупных проектах все равно одни и те же.

1. Зачем случайное число и куча рекурсивных проход

1. Желательно цитировать или как-то указывать ту область статьи, на которую пишется возражение или вопрос. К примеру вот это мне вообще не понятно к какому месту относится:
 

1. Зачем случайное число и куча рекурсивных проходов вверх по дереву, если пары alias+id (который unique primary key)и проверки по одному полю в таблице с индексом в нужном месте вполне хватило бы закрыть эту проблему.

И где этот PK alias+id и где я зачем-то по дереву вверх поднимаюсь?
 

Если бы у меня здесь были проблемы, я бы использовал этот метод. А если проблемы не было, то и париться мне не за чем было.
 

В консоли ограничений на выполнение php точно нет.

Не верное утверждение. Где-то нет, а где-то и есть. на том же таймвебе есть и консольные ограничения, и за 5 секунд потребления процессора более чем на 60% приводит к обрыву процесса.
 

3. Это скорее болезнь самого modx и его системы кеширования. Особо не придумать ничего. Разве то итемы каталога держать не в ресурсах

Там полно вариантов что можно придумать, начиная от простой заплатки cacheOptimizer, и заканчивая этим решением.
 

4. Стандартные решения удобны тем, что просты и понятны. Но на таких объемах я бы подумал о подключении какого-нибудь sphinx или провел бы серьезную денормализацию данных и возможно что-то положил бы в какой-нибудь redis или mongo или что там сейчас можно

Всегда надо держать грань между производительностью и простотой (для простоты сопровождения). Если скорость устраивает, то зачем еще усложнять? Усложнение будет задирать планку на специалистов для сопровождения.
 

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

1. Желательно цитировать или как-то указывать ту область статьи, на которую пишется возражение или вопрос. К примеру вот это мне вообще не понятно к какому месту относится: 1. Зачем случайное число и куча рекурсивных проходов вверх по дереву, если пары alias+id (который unique primary key)и проверки по одному полю в таблице с индексом в нужном месте вполне хватило бы закрыть эту проблему. И где этот PK alias+id и где я зачем-то по дереву вверх поднимаюсь? Печально, если нет :) Если бы у меня здесь были проблемы, я бы использовал этот метод. А если проблемы не было, то и париться мне не за чем было. В консоли ограничений на выполнение php точно нет. Не верное утверждение. Где-то нет, а где-то и есть. на том же таймвебе есть и консольные ограничения, и за 5 секунд потребления процессора более чем на 60% приводит к обрыву процесса. 3. Это скорее болезнь самого modx и его системы кеширования. Особо не придумать ничего. Разве то итемы каталога держать не в ресурсах Там полно вариантов что можно придумать, начиная от простой заплатки cacheOptimizer, и заканчивая этим решением. 4. Стандартные решения удобны тем, что просты и понятны. Но на таких объемах я бы подумал о подключении какого-нибудь sphinx или провел бы серьезную денормализацию данных и возможно что-то положил бы в какой-нибудь redis или mongo или что там сейчас можно Всегда надо держать грань между производительностью и простотой (для простоты сопровождения). Если скорость устраивает, то зачем еще усложнять? Усложнение будет задирать планку на специалистов для сопровождения. P.S. этот проект не на миллионы уников, так что сейчас мы не будем привлекать сюда все мощнейшие технологии. Мощнейшие проекты занимают не мало времени и как правило требуют участия группы программистов. А я это сделал за 2 дня. Так что здесь исходим из бюджетов и потребностей.

1. Желательно цитировать или как-то указывать ту о

прочел, поставил 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 пробовал ставил различные акселераторы, но такого эффекта добиться не смог! будьте добры подскажите в чем дело. Мне это покоя не дает)

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

Немного вклинюсь: не забывайте, что 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, оно не дало такой прир

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

Здорово, помогло на 100%! Спасибо

Вы еще следующую статью прочитайте: modxclub.ru/blog/research/176.html
 Переводите на phpTemplates+modxSmarty и вот тогда ощутите реальный прирост в производительности.

Вы еще следующую статью прочитайте: modxclub.ru/bl

Да я уже как раз этим и занят. Пробую на дохлом сайте

Да я уже как раз этим и занят. Пробую на дохлом са

В целом процедура совсем не сложная. 
 1. Устанавливаете phpTemplates+modxSmarty. 
 2. Код из MODX-шаблонов переносите как есть в Smarty-шаблоны.
 3. Создаете php-контроллер для статических MODX-шаблонов. Лучше всего использовать вот этот код: gist.github.com/Fi1osof/6023918
 4. MODX-шаблоны делаете статическими и всем им устанавливаете этот единый php-контроллер. В самих шаблонах создаете настройку tpl и указываете индивидуальные названия Smarty-шаблонов.
 5. Когда все заработает, меняете кешируемые MODX-теги на их Smarty-аналоги {chunk}, {snippet}, {config} и т.п.
 

P.S. Лучше всего, если Смарти-шаблоны будут расширением единого layout-шаблона. Тогда код будет более управляемым. Можете развернуть у себя сборку ShopModxBox и посмотреть как все это там работает.

В целом процедура совсем не сложная. 
 1. Устанавливаете phpTemplates+modxSmarty. 
 2. Код из MODX-шаблонов переносите как есть в Smarty-шаблоны.
 3. Создаете php-контроллер для статических MODX-шаблонов. Лучше всего использовать вот этот код: gist.github.com/Fi1osof/6023918
 4. MODX-шаблоны делаете статическими и всем им устанавливаете этот единый php-контроллер. В самих шаблонах создаете настройку tpl и указываете индивидуальные названия Smarty-шаблонов.
 5. Когда все заработает, меняете кешируемые MODX-теги на их Smarty-аналоги {chunk}, {snippet}, {config} и т.п. P.S. Лучше всего, если Смарти-шаблоны будут расширением единого layout-шаблона. Тогда код будет более управляемым. Можете развернуть у себя сборку ShopModxBox и посмотреть как все это там работает.

В целом процедура совсем не сложная. 
 1. Устанавл

Добрый вечер есть пару вопросов
 1 часто использую сниппет ClientConfig так сказать выношу все левые поля типо телефон компании тд для удобного редактирования
 он имеет плейхождео для вывода 
 так вот как же его вывести синтаксисом smarty если к примеру это поле выводить картинку и ее к тому же надо ее еще и обрезать с помощью phpthumbof
 вот на форуме нашол примерно то что надо но это не совсем то так сказать
 так как тут tv выводиться
 

2 есть такая проверка на значение tv поля на да или нет
 

как эту запись также перевести на php или smarty?
 

подскажите будьте добры

Добрый вечер есть пару вопросов
 1 часто использую сниппет ClientConfig так сказать выношу все левые поля типо телефон компании тд для удобного редактирования
 он имеет плейхождео для вывода 
 так вот как же его вывести синтаксисом smarty если к примеру это поле выводить картинку и ее к тому же надо ее еще и обрезать с помощью phpthumbof
 вот на форуме нашол примерно то что надо но это не совсем то так сказать
 так как тут tv выводиться <img src="{snippet name=«phpthumbof» params=«input=`{$object.image}`&options=`h=130&w=200`»}" /> 2 есть такая проверка на значение tv поля на да или нет `:else=`` как эту запись также перевести на php или smarty? подскажите будьте добры

Добрый вечер есть пару вопросов
 1 часто использую

Самое главное: вам в помощь будет в принципе знание php, поэтому если в знаниях php есть серьезные пробелы, то надо восполнять это, иначе просто никак.
 

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

1. Нет никаких проблем вызывать сниппет в Смарти, типа {snippet name=«ClientConfig» params=""}.
 2. Если сам сниппет не возвращает результат, а просто набивает данные в плейсхолдеры, есть тег {ph name=$placeholder_name}. Все имеющиеся плагины-теги: github.com/Fi1osof/modxSmarty/tree/master/core/components/modxsmarty/smarty_plugins 
 Вставляйте дальше по коду везде, где хочется. Только вот нельзя в таком виде их использовать, если у вас сниппет ClientConfig вызвается как обычный сниппет [[!ClientConfig]], ибо в таком случае его реальная обработка будет выполнена MODX только в самом конце парсинга, и на момент Smarty-тегов просто не будет этих плейсхолдеров.
 

2 есть такая проверка на значение tv поля на да или нет
 `:else=``
 как эту запись также перевести на php или smarty?

{field name=$tv_name assign=myparam}
{if $myparam}
    {$myparam}
{/if}

Самое главное: вам в помощь будет в принципе знание php, поэтому если в знаниях php есть серьезные пробелы, то надо восполнять это, иначе просто никак. 1 часто использую сниппет ClientConfig так сказать выношу все левые поля типо телефон компании тд для удобного редактирования
 он имеет плейхождео для вывода 1. Нет никаких проблем вызывать сниппет в Смарти, типа {snippet name=«ClientConfig» params=""}.
 2. Если сам сниппет не возвращает результат, а просто набивает данные в плейсхолдеры, есть тег {ph name=$placeholder_name}. Все имеющиеся плагины-теги: github.com/Fi1osof/modxSmarty/tree/master/core/components/modxsmarty/smarty_plugins 
 Вставляйте дальше по коду везде, где хочется. Только вот нельзя в таком виде их использовать, если у вас сниппет ClientConfig вызвается как обычный сниппет [[!ClientConfig]], ибо в таком случае его реальная обработка будет выполнена MODX только в самом конце парсинга, и на момент Smarty-тегов просто не будет этих плейсхолдеров. 2 есть такая проверка на значение tv поля на да или нет
 `:else=``
 как эту запись также перевести на php или smarty? {field name=$tv_name assign=myparam}
{if $myparam}
    {$myparam}
{/if}

Самое главное: вам в помощь будет в принципе знани

Спасибо большое за помощь!

Пожалуйста!

Обновил как вы посоветовали, и почему то получил PHP Version 5.4.26-1~dotdeb.0
 Хотелось бы уточнить, почему именно dotdeb, многие его не любят этот репозиторий, там корявые сборки модулей, и не всегда оптимизированы под конкретные задачи.