Я не совсем понял вопрос.
Вы имеете ввиду можно ли добавлять и включать свои собственные шаблоны? Да, в рамках синтаксиса смарти. Или что-то другое подразумевалось?
>Самое сложное при большой нагрузке — сделать так, чтобы при отсутствии (устаревании) кэша два практически одновременно полученных одинаковых запроса не начали генерировать страницу/блок параллельно
С этой проблемой я на определенном этапе столкнулся. В итоге, стал перед началом генерации данных ставить lock метку, если ее еще нет. Это позволило существенно снизить нагрузку в момент устаревания кэша.
>А вот есть ли в какой-нибудь CMS реализация дерева через Nested sets из коробки?
Изначально была идея реализовать и nested sets тоже… Даже таблицу иерархии сделал отдельно, чтобы можно было использовать либо одну, либо другую… Но через некоторое время дрогнул, таблицы объединил, а про nested sets забыл до лучших времен:)
При первой генерации элемента дерева, в него складывается информация, которую неразумно генерировать каждый раз (список подключенных модулей, настройки, права доступа и т.п. После чего объект сохраняется на диск. Среди прочего, объект содержит частичную информацию об имеющихся дизайнах и шаблонах (пока, к сожалению, не полную, но со временем я это исправлю). Вот на этапе генерации объекта — file_exists, при следующих запросах — опрос свойств объекта.
Практически все вышеизложенное можно реализовать. Не из коробки, конечно, но путем наращивания функционала модулей. Сам движок для этого пилить не придется.
Первый результат я получил на четырехядерном Xeon E5430 2.66GHz.
Во втором случае было «что-то шестиядерное» + memcache:)
Скорее всего, Ваши результаты связаны с тем, что по умолчанию после установки включен режим отладки, который полностью подавляет любое промежуточное кэширование на всех этапах.
К главной странице будет подключен модуль отвечающий за вывод топа новостей, а к странице с новостями — соответствующий модуль. Если же подразумевается что на сайте вообще нет контента кроме новостей, то и генерацию топа я бы возложил на модуль новостей и повесил его прямо на главную.
Элементы дерева могут так же быть внешними, внутренними ссылками или даже алиасами.
Очень большое количество элементов в дереве, скорее всего, будет говорить о неправильном проектировании сайта, так как большую часть навигации выполняют сами модули. Движку-же надо только определить какие модули необходимо подключить.
На самом деле, примерно к тому же я и пришел. Только в некоторых случаях я спустился даже не к кэшированию блоков, а к кэшированию запросов к БД. Это полезно в тех случаях, когда внешний вид страницы сильно зависит от настроек пользователя. В итоге вариантов HTML получается множество, повторная их востребованность невелика, а запросы к БД примерно одни и те же.
С главным шаблоном имеется такая проблема. Можно пойти двумя путями: указать некэшируемые области (именно там, где подставляются более мелкие блоки), либо наоборот — указать что именно кэшировать. Я пока попробовал первый способ.
Обращение пользователя происходит к элементу сайта, который может иметь много модулей, а не к конкретному модулю. То что от пользователя поступила команда модулю смены скина, модуль расчетов даже не подозревает. Равно как и вообще не подозревает о его существовании — просто делает свою часть работы.
Я в статье привел пример. Наверное, я изложил его несколько путано. Попробую еще раз:
Предположим, на странице два модуля. Один из них позволяет переключить пользователю отображаемый скин, а второй занимается некими тяжелыми подсчетами. 99% времени модуль переключения скина ничего не делает, так как нет команды от пользователя, но когда такая команда есть — он должен изменить настройки и осуществить редирект. Неразумно его подключать после модуля расчетов, так как сначала будут произведены расчеты, а потом произведен редирект и пользователь результатов расчетов все равно не увидит.
Так же я уже написал что разделил модули на три больших группы, которые подключаются по очереди.
Вы имеете ввиду можно ли добавлять и включать свои собственные шаблоны? Да, в рамках синтаксиса смарти. Или что-то другое подразумевалось?
С этой проблемой я на определенном этапе столкнулся. В итоге, стал перед началом генерации данных ставить lock метку, если ее еще нет. Это позволило существенно снизить нагрузку в момент устаревания кэша.
Изначально была идея реализовать и nested sets тоже… Даже таблицу иерархии сделал отдельно, чтобы можно было использовать либо одну, либо другую… Но через некоторое время дрогнул, таблицы объединил, а про nested sets забыл до лучших времен:)
Во втором случае было «что-то шестиядерное» + memcache:)
Скорее всего, Ваши результаты связаны с тем, что по умолчанию после установки включен режим отладки, который полностью подавляет любое промежуточное кэширование на всех этапах.
Спасибо за пожелание!
Очень большое количество элементов в дереве, скорее всего, будет говорить о неправильном проектировании сайта, так как большую часть навигации выполняют сами модули. Движку-же надо только определить какие модули необходимо подключить.
У меня эти данные хранятся в настройках узла, но могут быть изменены любым из подключаемых модулей.
С главным шаблоном имеется такая проблема. Можно пойти двумя путями: указать некэшируемые области (именно там, где подставляются более мелкие блоки), либо наоборот — указать что именно кэшировать. Я пока попробовал первый способ.
Нет. В групе порядок уже не важен.
Предположим, на странице два модуля. Один из них позволяет переключить пользователю отображаемый скин, а второй занимается некими тяжелыми подсчетами. 99% времени модуль переключения скина ничего не делает, так как нет команды от пользователя, но когда такая команда есть — он должен изменить настройки и осуществить редирект. Неразумно его подключать после модуля расчетов, так как сначала будут произведены расчеты, а потом произведен редирект и пользователь результатов расчетов все равно не увидит.
Так же я уже написал что разделил модули на три больших группы, которые подключаются по очереди.