Еще один модуль кэширования. Обещают шоколад

Главные вкладки

Аватар пользователя dyp@drupal.org dyp@drupal.org 16 октября 2006 в 13:55

Модуль:
http://drupal.org/project/boost
Описание и тесты:
http://bendiken.net/2006/05/28/static-page-caching-for-drupal
Если честно сам не читал, посмотрел на тесты, что-то фантастическое. Если есть у кого время гляньте плз.

Комментарии

Аватар пользователя smile smile 21 октября 2006 в 19:36

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

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

Аватар пользователя dyp@drupal.org dyp@drupal.org 21 октября 2006 в 20:48

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

Чтобы выводы делать для начала надо попробовать. Идея вобщем-то не нова. Повторяет суть другого модуля
http://drupal.org/project/fastpath_fscache
Только лучше (по словам автора).

Аватар пользователя smile smile 23 октября 2006 в 14:23

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

Аватар пользователя axel axel 23 ноября 2006 в 17:01

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

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

Аватар пользователя kiev1 kiev1 3 декабря 2006 в 22:42

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

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

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

Аватар пользователя ultraboy@drupal.org ultraboy@drupal.org 4 декабря 2006 в 1:45

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

Аватар пользователя kiev1 kiev1 5 декабря 2006 в 1:33

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

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

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

Аватар пользователя rapitosov@drupal.org rapitosov@drupal.org 5 декабря 2006 в 2:40

Механизм кеширования Друпала изначально рассчитан не на СНИЖЕНИЕ_ВРЕМЕНИ_ГЕНЕРАЦИИ_КАЖДОЙ_СТРАНИЦЫ, а на ситуации, когда НА_САЙТ_СЛУЧАЕТСЯ_МАССОВЫЙ_НАПЛЫВ_ПОСЕТИТЕЛЕЙ. Разработчики считают (и они по своему правы), что сайт в нормальных условиях должен генерировать каждую(!) страничку с нуля. Они особо выделяют ситуации, когда на сайт появляется ссылка на каком-нибудь новостном портале и туева хуча пользователей портала желает ознакомится с сайтом. В подобных ситуациях (когда в час уходит больше 1000 копий одной страницы) и срабатывает механизм кеширования (и очень сильно помогает).

Вы изначально ставите задачу в другой плоскости, и удивляетесь, почему Вам не подходит механизм кеширования Друпала. Повторю ещё раз: "Механизм кеширования друпала не предназначен для уменьшения времени генерации каждой страницы, а только на снижение нагрузки при массовым наплыве на несколько страниц сайта". Если Вас не устраивает скорость обработки ЛЮБОЙ СТРАНИЦЫ, ищите нормальный хостинг, ставьте reverse-proxy, дожидайтесь релиза модуля boost, используйте другую CMS или создавайте сайт в HTML.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы

Аватар пользователя kiev1 kiev1 5 декабря 2006 в 7:52

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

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

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

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

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

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

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

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

Аватар пользователя rapitosov@drupal.org rapitosov@drupal.org 5 декабря 2006 в 8:30

Ваши утверждения голословны. Прошу прояснить, что Вами подразумевается под "нормальными CMS" и почему Вы тратите своё драгоценное время на форуме "ненормальной CMS", Вам больше нечем занятся? Тем более, что обсуждение вопроса кеширования с русскоязычными пользователями Друпала, которые не учавствуют в разработке ядра, вряд ли принесёт результат. Так же прошу предоставить результаты тестирования Друпала против "нормальных CMS", и указать какой хостинг "стонет" от одного Друпала.

Убедительно прошу прекратить истерику и перейти к нормальной беседе, как это принято у взрослых людей.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы

Аватар пользователя Dan Dan 5 декабря 2006 в 8:09

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

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

Аватар пользователя kiev1 kiev1 5 декабря 2006 в 8:32

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

Аватар пользователя Dan Dan 5 декабря 2006 в 9:51

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

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

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

Аватар пользователя rapitosov@drupal.org rapitosov@drupal.org 5 декабря 2006 в 10:12

Кэшировать новость/блог/и т.д. не имеет смысла.
Нет, почему же. Можно сэкономить пару милисекунд пропуская работу фильтров (кроме обработчика PHP). Другое дело, что смысла в этом конечно нет.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы

Аватар пользователя inc inc 5 декабря 2006 в 11:50

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

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

Аватар пользователя les les 5 декабря 2006 в 12:46

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

Аватар пользователя les les 5 декабря 2006 в 13:05

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

Аватар пользователя clubwave.ru clubwave.ru 11 декабря 2006 в 17:19

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

Так значит ноды для анонимусов живут в кэше всё время? тоесть старая старая статься, которую только смотрят а не меняют будет всегда браться из кэша одним запросом? Если это так то я буду спать спокойно Smile

Аватар пользователя axel axel 5 декабря 2006 в 20:49

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

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

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

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

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

Аватар пользователя rapitosov@drupal.org rapitosov@drupal.org 6 декабря 2006 в 1:08

Великое древнее учение о вебстандартах и юзабилити говорит нам, что URL делится на две части знаком вопроса. Передняя, довопросительная часть, есть уникальная ссылка на уникальную страницу. Послевопросительная же часть указывает в каком виде подать эту страницу, или куда перейти после отправки формы с этой страницы. Так что URL с параметрами нужны для придания той же страницы большей гибкости, например всмысле сортирования таблицы, что сильно помогает посетителям, но абсолютно монопенисуально поисковикам.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы

Аватар пользователя axel axel 14 декабря 2006 в 12:33

Новая версия boost работает без страшных глюков. Поставил себе на www.roleplay.ru, хоть сайт и непосещаемый, но для теста в самый раз. Работает пока нормально, жду версии под 5.0 для установки на drupal.ru.

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

Аватар пользователя axel axel 6 декабря 2006 в 3:23

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

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

Аватар пользователя moonman moonman 14 декабря 2006 в 15:22

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

Аватар пользователя rapitosov@drupal.org rapitosov@drupal.org 14 декабря 2006 в 22:47

На технологии AJAX построен модуль ядра upload.module начиная с версии 4.7 Так же имеется несколько сторонних модулей, находящихся в глубокой альфе.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы

Аватар пользователя axel axel 15 декабря 2006 в 4:22

AJAX также используется во многих местах движка в полях с автодополнением. Появился AJAX в Drupal 4.7 и используется в разных модулях, их не так уж мало - см. на drupal.org. А в Drupal 5 добавлена поддержка jquery - библиотеки для javascript, которая позволяет в том числе всякие штуки с AJAX.

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

Аватар пользователя moonman moonman 14 декабря 2006 в 22:54

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

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

Аватар пользователя rapitosov@drupal.org rapitosov@drupal.org 14 декабря 2006 в 23:00

предпросмотр отправляемого материала через AJAX, всякие другие фишки... уже многими движками делается
Мы готовы исправить это досадное упущение за скромное вознаграждение Smile
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы

Аватар пользователя moonman moonman 15 декабря 2006 в 0:14

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

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

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

Аватар пользователя ultraboy@drupal.org ultraboy@drupal.org 15 декабря 2006 в 12:28

А что ты имеешь в виду конкретно против его AJAXa? Какие глюки, ты о своих талантах, видимо?

Ты начал жаловаться на отсутствие фукнционала. (Заметь, мы говорим о БЕСПЛАТНОМ продукте). Сам, видимо, исправить это ты не можешь. Тебе ясно дали понять что ты можешь заплатить - чтобы улучшить друпал.

Не надо ныть и жаловаться. Если что-то не нравится - исправляй. Своей работой или деньгами. А разработчики тебе ничего не должны.

Аватар пользователя moonman moonman 15 декабря 2006 в 13:22

Кто ноет то?

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

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

Аватар пользователя Toologic Toologic 7 февраля 2007 в 15:28

Что получил:

Ошибка 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 создал. Права записи все.

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

Аватар пользователя kiev1 kiev1 13 апреля 2008 в 0:30

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