[TIP] Ускорение работы сниппетов.

Спасибо за подробные разъяснения

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

При установке (+ подправка в index.php чтобы не перебивался DOCTYPE) теряется результат [+wf.alias+] в чанках (определяет адреса иконок в меню).

И вообще что ещё можете посоветовать по ускорению сайта?
Сайт http://www.nash-gorod.net на MODx Evolution 1.04
Разбила на подсайты на поддоменах, этого мало.
Имеет ли смысл при решении проблемы переходить на выделенку?

И какие ещё разработки можно применить, если сайты уже готовы, структуру поменять невозможно? С PHP знакома поверхностно...

Именно эта библиотека у меня используется в еще не выпущенном плагине - довольно хорошая вещь. Спасибо, Andchir , за ссылку. Если Вы не против, то я воспользуюсь вашим слегка исправленным вариантом и внедрю его в свой плагин? Чтобы все преимущества были в одном месте.

большое спасибо за ответы и за Вашу работу. подожду выпуска общего плагина.

а по поводу обнуляющихся [+wf.alias+] (после установки сабжа) - недоработка или моя ошибка?
( вложенность: шаблон -> tv-параметр -> чанк -> вызов Wayfinder -> чанк c [+wf.alias+] )
-----------------------------------------
и ещё вопрос: перейти с обычного хостинга на VPS - даёт какие-то ощутимые результаты?

Quote from: Jassie at Feb 26, 2011, 09:51 AM

большое спасибо за ответы и за Вашу работу. подожду выпуска общего плагина.

а по поводу обнуляющихся [+wf.alias+] (после установки сабжа) - недоработка или моя ошибка?
( вложенность: шаблон -> tv-параметр -> чанк -> вызов Wayfinder -> чанк c [+wf.alias+] )
-----------------------------------------
и ещё вопрос: перейти с обычного хостинга на VPS - даёт какие-то ощутимые результаты?

Зачем запихивать в TV чанк с меню, не проще ли сразу в шаблоне логику создать.

Quote from: antey at Feb 26, 2011, 10:01 AM

Зачем запихивать в TV чанк с меню, не проще ли сразу в шаблоне логику создать.

Сайт со сложной структурой, был выбор
(1) либо N шаблонов,
(2) либо 1 шаблон, в котором n "альтернативных" мест вынесены в tv-параметры (выбора чанков).
N>>n
Для разработки конечно проще вариант (2). С точки зрения скорости работы сайта, как теперь понимаю - лучше (1).
Изначально выбор был сделан (2), теперь пытаюсь ускорить то что получилось. В любом случае, учимся на своих ошибках.

Quote from: Jassie at Feb 26, 2011, 11:32 AM

Изначально выбор был сделан (2), теперь пытаюсь ускорить то что получилось. В любом случае, учимся на своих ошибках.

Все это достаточно спорно, в действительности все зависит от того, как вообще реализована логика сайта.
Кстати, по ссылке говорится об уменьшении количества запросов к БД, но в принципе это не должно никого особенно интересовать, главное – уменьшить общее время выполнения скриптов. То есть, если страница генерируется, например, за 0,5 секунды, а на 15 запросов к базе тратится 0,05 секунды, то не надо уменьшать количество запросов, надо оптимизировать логику работы.

Quote from: AKots at Feb 26, 2011, 12:14 PM

Quote from: Jassie at Feb 26, 2011, 11:32 AM

Изначально выбор был сделан (2), теперь пытаюсь ускорить то что получилось. В любом случае, учимся на своих ошибках.

Все это достаточно спорно, в действительности все зависит от того, как вообще реализована логика сайта.
Кстати, по ссылке говорится об уменьшении количества запросов к БД, но в принципе это не должно никого особенно интересовать, главное – уменьшить общее время выполнения скриптов. То есть, если страница генерируется, например, за 0,5 секунды, а на 15 запросов к базе тратится 0,05 секунды, то не надо уменьшать количество запросов, надо оптимизировать логику работы.

Тоже согласен про логику работы. НО! Суть в том, что данный вариант кеширования позволяет однажды сгенерировать результат выполнения скриптов, а потом повторно загружать уже закешированный результат, без выполнения кода. Т.е. время отдачи контента будет мизерным - столько, сколько уйдет на считывание файла-кеша и отдача браузеру.

Поэтому можете воспользоваться предложенным Andchir способом. А когда подспеет мой плагин, просто установите его.

Quote from: AKots at Feb 26, 2011, 12:14 PM

Все это достаточно спорно, в действительности все зависит от того, как вообще реализована логика сайта.
Кстати, по ссылке говорится об уменьшении количества запросов к БД, но в принципе это не должно никого особенно интересовать, главное – уменьшить общее время выполнения скриптов. То есть, если страница генерируется, например, за 0,5 секунды, а на 15 запросов к базе тратится 0,05 секунды, то не надо уменьшать количество запросов, надо оптимизировать логику работы.

Вы работали с высоконагрузочными системами?
Как раз таки запросы к базе, как правило, и кладут систему. Ничего не стоит прожевать скрипты тому-же eAccelerator. Или, как обычно делается, разнести скриптовые бэкенды.
А базу оставить на отдельном сервере. Так вот, эти скриптовые бэкенды плодить - ничего не стоит. А если не справляется база, то ее надо расшардивать. А масштабирование базы сразу вызывает ряд сложностей. Сетевые транзакции, мутексы и тд. Сразу сильно усложняется код и понижается стабильность работы.
С уважением.

Quote from: thebat053 at Feb 28, 2011, 12:41 PM

Вы работали с высоконагрузочными системами?
Как раз таки запросы к базе, как правило, и кладут систему.

В принципе MODx не рассчитана на такие системы, для них надо использовать что-то другое.