описание клевое, но я что-то не вижу ссылочки "download".

наверное в разработке ещё...

свежо придание, но верится с трудом.

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

дык я чтоли против попробовать? покажите что можно попробовать, я попробую. пока ничего кроме пространных текстов (с галимым шрифтом кстати) и красивых графиков я не вижу.

http://drupal.org/project/boost
пока только в cvs

There are no published releases for this project. Recently added releases will not be published until the packaging scripts have run.

Куда выложили?

С похожей идеей возился под 4.5 ("IcedDrupal"), но тогда в друпале не было AJAX (http://www.drupal.ru/node/769), было отложено до лучших времён, но под 4.7 так и не портировал. Надеюсь автору хватит сил довести идею до релиза.

--
Axel,
администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!

и он даже работает (как задумано, но совсем не так как в нормальных CMS)

он унаследовал неприятнейший баг друпаловского кеширования: странички которые никто не менял просто самопроизвольно исчезают через время указанное в настройках (lifetime) из кеша и заново запрашиваются из базы - кеш полностью теряет свой смысл ((( а разработчики как я понял говорят что так и надо - весь трагизм ситуации описан тут -> http://drupal.org/node/101125

радует только одно - модуль Boost не добавляет тормозов...

ну как-же можно не понимать очевидного - если на сайте 10 страничек и их все запрашивать каждые 10 минут - то согласен - кеш ровно наполовину имеет смысл. Наводящий вопрос - а если 20 страничек, а если 100, а когда 3000 то сколько раз в 10 минут надо запросить КАЖДУЮ страничку что-б кеш себя оправдал?

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

Ответ: если у меня страничек 3000 а минимальное время жизни кеша 10 минут (мне надо сразу видеть изменения на сайте) - то кеш начнет иметь смысл при более 3000 запросах КАЖДОЙ странички за 10 минут - то есть при увеличении страниц на сайте более 100 - кеш начинает приобретать отрицательный смысл - то есть тормозить систему.

Очень странное понимание "кеша" (((

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

Скажу по секрету - нормальных CMS с нормальным кешированием на одном сервере может вполне уживатся несколько сотен... и один друпал... грустно...

Зачем попусту расходовать ресурсы когда страничку (не считая блоков) можно один раз сгенерить и больше не трогать? Как и делается во многих CMS. Посчитайте к примеру сколько запросов уходит на формирование страницы с лентами тейсеров раздела? по 300 и более!

А модуль Boost как выяснилось... держитесь крепче за стул... - он оказалось не кеширует вообще вторые, третьи, и тд страницы разделов - только первую - и только на 10 минут... ))) и не баг это а так задумано...

И так-ли часто случается такой сумасшедший наплыв юзеров которые к примеру 50 лежащих на поверхности (на главной) - страничек запросят за 10 минут? 5 тысяч юзеров в день тусующихся исключительно на главных страничках - вы видели? я нет - у меня большинство приходит с поисковиков и отнюдь не на главную страничку.
Зато я видел как лихо с десяток ботов обходят по кругу неосторожно оставленный на главной страничке календарь и методично так кликают на все его дни вплоть до первого дня создания сайта - догадайтесь сколько на выборку страниц отображения ленты одного дня уходит запросов? а умножить на 10 ботов? а на количество клиентов с друпалами? бедный хостер... а если календарь не только на главной? - конец серверу ... а теперь еще надо на каждую страничку создать кеш, вогнать его в mysql или положить на диск и через 10 минут прибить... очень остроумно!
Короче снес я со своего сайта этот Boost вплоть до момента осознания авторами принципов элементарного кеширования.

Хотя да - похоже кто-то из разработчиков друпал, не прошло и 5-ти лет, начал догадыватся что с кешированим что-то не так - и начали к 6-й версии соображать http://drupal.org/node/65017 (Set cached pages to more reasonable age.)

Да просто у меня есть с чем сравнить - стоит у меня на хостинге несколько посещаемых сайтов на простых полу самделашных CMS в которых и функционала то нет толком, а кэш есть - и все летает - возьмите - сравните вот этот с любым из друпаловских - CMS там простейшая - а стоит рядом один друпал на одном сервере - 300 запросов на страницу раздела - страничка формируется от секунды до 3-х... обидно.

kiev1, а тебе не кажется странным, что сайт drupal.org, на котором десятки тысяч нодов работает со стандартным кешем?
этот вопрос уже прорабатывался на этом форуме - всё не так просто. ты предлагаешь кэшировать все страницы и сохранять их в кэше навечно (до изменения). но как определить, что страница изменилась? и что ты подразумеваешь под страницей?
Если страница - это то, что видит пользователь, то десяти минут - выше крыши, ибо если есть блоки типа "кто на сайте" или тот же календарь, которые могут измениться в любой момент, то страницу надо пересохранять в кэше. если же сохранять интелектуально (блочно, анализируя изменения для каждого модуля), то, имхо, система кэша будет сравнима по нагрузке со штатной системой отдачи контента.
Если же страница - это основное содержимое ("средняя колонка"), то сохранять в кэше вообще нет смысла - она и так отдельно в базе лежит.

http://drupal.org/node/65017 - я бы дал этому категорю не feature, а bug

а тебе не кажется странным, что сайт drupal.org, на котором десятки тысяч нодов работает со стандартным кешем?
так ведь умер у них прошлый сервер под нагрузкой - не помните как на новый деньги собирали? теперь для одного сайта - целый сервер.
но как определить, что страница изменилась?
а что она живет отдельной жизнью? разве не редактор сайта их добавляет и меняет? вот нажали "редактировать/сохранить" - вот она и изменилась - а в друпале в таблице если присмотрется то там даже такое поле у нод есть - "дата изменения".
ибо если есть блоки типа
я не про блоки - я про ноды и ленты разделов, особенно про ленты разделов, ну и ноды которые формируются часто не сразу из базы а собираются из кусочков как в флексиноде или cck.
А для блоков уже есть неплохой модуль кеширования по типу постнука 5-ти летней давности - там это в ядре было - назывался параметр "период обновления блока", с той разницей что в друпале когда он включен такая каша в админке блоков творится что хочется сразу его отключить.

"умер у них прошлый сервер под нагрузкой"
Как связан кэш со смертью сервера? Это проблемы железа.

dan: "но как определить, что страница изменилась?"
kiev1: "а что она живет отдельной жизнью?"
Я имел ввиду страницу как единое целое из нескольких блоков. Кэшировать новость/блог/и т.д. не имеет смысла.

"особенно про ленты разделов, ну и ноды которые формируются часто не сразу из базы а собираются из кусочков как в флексиноде или cck."
Это сложные ноды, которые включают в себя вкрапления из php кода. А код в разное время может давать разные результаты, как определить, когда надо обновлять? Алгоритм [нажали "редактировать/сохранить" - вот она и изменилась] тут не пройдёт.

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

PS кэш находится в подкаталоге templates_c каталога темы оформления(при использовании друпала).

В cakephp тоже можно запретить кэширование на отдельные области страницы.
В конечном счете, почему-бы не закладывать в ядро возможность реализации собственной системы кэширования, отличной от "родной"? В версии 5.0 есть слабый намек на это в виде функции page_cache_fastpath(). Хорошо хоть появился агрессивный режим кэша, а то в 4.7 мне пришлось руками "поправить" функцию drupal_page_header() чтобы сделать тоже самое.

В 5.0, да и в 4.7, странички будут жить в кэше вечно, если на сайт ходят только анонимусы. Lifetime начинает отсчет, кода вызывется функция cache_clear_all(), например, когда нажали кнопку сохранить при редактировании ноды.

Потерявшись в ветках дискуссии отвечаю на первый пост.

Кеширование для анонимных пользователей в Drupal сделано вполне эффективно (хотя по-прежнему есть куда улучшать). См. результаты сравнения Drupal с популярной CMS Mambo: http://buytaert.net/drupal-vs-joomla-performance - разница в реализации кэшей видна невооружённым взглядом А в 5.0 кеширование более эффективно и сам движок работает побыстрей.

С модулем boost нагрузку можно ещё значительно снизить, несмотря на ограниченное время работы кеша. Но просто так увеличить время кеширования нельзя - сайт потеряет в динамичности. Однако тут решать админу сайта и время кеширования неплохо бы вынести в настройки (не будем забывать, что пока вышла альфа-версия модуля и наверняка в нём произойдёт немло изменений). Пока я включил boost на живом сайте и выключил обратно, когда через полдня увидел, что для анонимусов отображается почему-то страница с контентом, который висел на главной странице месяца три назад. Не понимаю отчего такой глюк вылез, подожду более стабильной версии модуля. Однако, смотря по статистике drupal.ru - значительная часть посетителей приходит на главную страницу, ещё очень многие забирают RSS - размещение этих страниц в статических файлах, что собственно и позволяет boost, очень бы снизило нагрузку.

В любом случае идея boost очень здравая. Если ещё добавить возможность подгрузки блоков посредством AJAX - это могло бы в какой-то мере решить проблему устаревающих страниц в кеше. И теоретически можно сделать поддержку кеширования URL с параметрами - это можно разрулить правилами в mod_rewrite (сейчас кешируются любые URL не содержащие параметров, другое дело что в друпале с его clean URL не очень понятно, почему вообще вылезают такие URL слишком во многих местах где они имхо не нужны, например см. страницы pager).

--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!

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

--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!

Народ, извиняюсь что вклиниваюсь в высокоинтелектуальные беседы...
Но тут много упоминалось про технологию AJAX, которая якобы используется Друпалом...
Где это можно увидеть? И как это можно сделать для своего сайта? Я лично ещё нигде этого AJAX-са не наблюдал ни на одном друпаловском движке...

Понятно.
Просто не юзал загрузки, поэтому не знаю.

Но вообще предпросмотр отправляемого материала через AJAX, всякие другие фишки... уже многими движками делается, это очень удобно и значительно снижает загруженность сервера..
Загрузки имхо вещь весьма редкая и у многих отключаемая, такчто почти и ненужная.

Угу, типа "работаю волшебником"....
Потом буду иметь вналичии:
+ глюки Друпала
+ глюки твоего AJAX-са
- WMZ

:)))))))))))))

Не, лучше пусть будет "это досадное упущение"....

Кто ноет то?

Зашёл в тему...прочитал про то что в Друпале пользуют AJAX.
Ответили типа в загрузках юзай.
Ну я загрузки не юзаю, такчто в пролёте тут AJAX для меня.
Оказалось что ещё в некоторых модулях, которые тоже не юзал, не знаю.

Вот я и дал инфу по типу что многие движки уже переходят на AJAX в тех местах где происходит обновление и с помощью AJAX-са можно избежать лишних запросов и нагрузок.
...
Тут ты вклиниваешься со своим предложением....
И теперь говоришь что я типа "ною"...
Не тормози.... ))))))))))))

Что получил:

Ошибка PHP
symlink() [function.symlink]: open_basedir restriction in effect. File(/home/node/3980.html) is not within the allowed path(s): (/home/u37190/) в файле /home/u37190/travelweekly.ru/www/modules/boost/boost.helpers.inc на строке 83.

Ошибка Boost
Unable to create symlink: /home/u37190/travelweekly.ru/www/cache/travelweekly.ru/0/2007/02/06/4270.html to /home/u37190/travelweekly.ru/www/cache/travelweekly.ru/0/node/4270.html

Ну ессеснА - таких сообщений ТЬМА.
-каталог cache создал. Права записи все.

Кто-нить сталкивался?

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