9 июля 2009 в 9:38
На площадках с низкой вычислительной производительностью единственным разумным способом оптимизации движка сайта может оказаться только кэширование. В Drupal отсутствует многоуровневое кэширование генерируемого контента, а полное кэширование страниц позволяет оптимизировать отображение информации для анонимных посетителей, но вместе с тем лишает сайт динамичности. Мы попытались реализовать продвинутое многоуровневое контекстнозависимое кэширование содержимого в рамках модуля CacheExtra.
Для тех, кто заинтересовался разработкой, вот краткий список того, что этот модуль делает:
- Кэширование объектов node;
- Кэширование страниц материалов (node/$nid);
- Кэширование главной страницы со списком материалов (node);
- Кэширование ленты списка материалов (rss.xml);
- Кэширование страниц материалов по терминам таксономии;
- Кэширование лент терминов;
- Кэширование комментариев;
- Независимое включение/выключение всех кэшей;
- Автоматическое удаление зависимых кэшей при создании, правке, удалении материалов;
- Автоматическое удаление зависимых кэшей при добавлении, правке, удалении комментариев;
- Функция принудительной очистки данных кэша, созданных этим модулем;
- Возможность отладки кэша;
- Сохранение в кэше установленного заголовка, breadcrumb, подключенных стилей, скриптов;
- API для использования возможностей модуля в других модулях, генерирующих контент.
Вывод отладочной информации включается в настройках и показывается пользователям с соответствующей привилегией или при передаче методом GET аргумента CACHEXTRA_DEBUG. Описание API для использования возможностей в других модулях будет чуть позднее.
Также хотелось бы предупредить о возможных проблемах при использовании этого модуля. Например, может неправильно работать выбор шаблонов функциями препроцессинга в движке темы. Хотя отчасти это уже удалось исправить. Также будьте осторожны, если используете глобальные переменные в шаблонах темы. Возможны другие побочные эффекты, которые пока не выяснены.
P.S. Хотелось бы напоследок порекомендовать использование модуля совместно с CacheRouter.
| Вложение | Размер |
|---|---|
 cachextra-6.x-1.0-beta.tar_.bz2 | 10.42 КБ |
Комментарии
Зачем вы повторяете повторяете?
Где же тесты и сравнения с сущестувующими решениями или, по крайней мере, со стандартным механизмом снижения нагрузки?
ну во-первых, подобных решений мною не было найдено. если вы знаете что-то такое же по смыслу, тыкните меня носом, буду только благодарить.
во-вторых, этот вариант кэширования естественно будет медленнее стандартного кэша страниц целиком для анонимных посетителей. однако, отображаемый контент будет обновляться сразу же после любых изменений, в стандартном механизме только после истечения заданного времени покуда произойдет flushing.
о каких именно стандартных механизмах снижения нагрузки идет речь?
если о кэшировании страниц для анонимных посетителей, то об этом я отписался вышел.
если о Throttle, то он мне как и многим откровенно не нравится своей сутью.
boost authcache cacherouter
This module provides static page caching for Drupal 4.7 (unsupported), 5.x (looking for a maintainer) and 6.x (thread about 6.x development), enabling a very significant performance and scalability boost for heavily-trafficked Drupal sites that receive mostly anonymous traffic.
не то.
уже интересней, но тоже не то.
[#31523]тут[/#]
снова не то.
Не имеет смысла:
* Кэширование объектов node;
* Кэширование страниц материалов (node/$nid);
* Кэширование комментариев;
* Сохранение в кэше установленного заголовка, breadcrumb, подключенных стилей, скриптов;
не пойму в чем отличие:
* Кэширование страниц материалов по терминам таксономии;
* Кэширование лент терминов;
Думаю не стоит объяснять чем многоуровневая схема кэширования отличается от кэширования страниц целиком.
Кэширование объектов node имеет смысл, если включено много модулей, использующих nodeapi, поскольку вы избегаете выполнения десятков запросов в node_load. Если это оказывается не эффективно, можно отключить.
У меня есть сайт с фоторепортажами, при просмотре альбома (страница node/$nid) node_load и node_view выполняется множество раз (1 на альбом + N на количество фотографий) не верю, что в этом случае кэширование содержимого таких страниц бесполезно.
Кэширование комментариев ну тут до кучи по желанию.
Если не сохранять в кэше заголовок, breadcrumb, ссылки на подключаемые в процессе формирования кэшируемого содержимого стили и скрипты, все это соответственно не будет восстановлено при загрузке данных из кэша.
Отличие: taxonomy/term/% и taxonomy/term/%/feed, правда я не понял, почему отображение лент для материалов по термину убрали, но это легко включить.
функция node_load() статически кеширует сама в себе объект $node, если вы один раз загрузили ноду, то при последующих вызовах этой функции запросы к базе не повторяются.
ну дак человек кладет объект в БД, что эффективнее , но неразумно, тк данные загружаются в зависимости от юзера. модуль poll не даст голосовать например и тд.
если я ошибся поправьте.
во-1х данные кэшируются в зависимости от юзера.
во-2х если не ошибаюсь обработка в модуле poll производится не при загрузке.
в-3х при любых изменениях данных этот кэш автоматически сбрасывается.
Кэширование объектов нод, и даже темизированной ноды - очень даже имеет смысл, даже не смотря на то, что они зависят от юзера. Если я, например, знаю, что какие-то ноды всегда одинаковы, почему я не могу включить принудительное кэширование именно этих нод?
Или, как тут уже писали, сделать кэширование по ролям/юзерам (более реально, наверное, первое).
Кстати, я это принудительное кэширование уже предлагал на drupal.org, но они FieldsAPI доводят до ума, и этот вопрос отложили до лучших времен.
Нет смысла кешировать ноду т.к. затраты на получение кеша, сопоставимы с затратами на получение ноды.
Я думаю, что получить полностью готовый объект ноды из базы все же быстрее, чем вызов node_load(). Т.е. грубо говоря, простой select по nid.
А про кэширование темизированной ноды и сомневаться нечего, потому что каждая нода темизируется при помощи темплейта, а это долго (ф-ии темизации быстрее). Я сам как-то замерял производительность. Не катастрофично, конечно, но на посещаемом сайте наверняка будет заметно. Точных цифр, к сожалению, предоставить не могу.
Похоже, что у вас получается очень интересное решение, но всё-таки также хотелось бы присоединиться:
Да, понятно, что Ваше решение значительно провосходит по функционалу эти самые "стандартные механизмы", но Вы ведь сами пишете:
Поэтому будет очень интересно, если Вы расшифруете - насколько медленнее... ну а также - в каких случаях быстрее и также насколько.
Мож я туплю слегка, но ниче...
Как я понял - медленнее на процент некешируемых частей. так? Но в то же время при стандартном кешировании все равно происходит проверка страниц на обновление, ну а если закешировать все стабильное раз и навсегда -было бы круто. Лишь бы Сапа, контекст и т.п. работало))
Сделал 15 сателлитов на Вордпрессе. система громоздкая, уже 11,5 мб движок весит. и что там есть)) Вот вспомнил о Друпале и вернулся на сайт. А как было бы хорошо импортировать темы с других движков модулем, а еще выводить в конце адреса кешированных страниц - html, Яша его так любит, у многих не туник все висит и висит ссылками набитый)).
А еще вот чего!Нужен модуль, чтобы рубить пустые места. комментарии в двиге. тогда бы многие модули выполнялись бы быстрее, я думаю. хотя бы чуть. Или я глючу, но уже ночь. До форума не доползу)).