Comments 66
Поясните, пожалуйста, про кэш на уровне ngnx.
Вот эта страница для анонимуса будет закеширована на час? www.hr-portal.ru/forum/ispytatelnyi-srok-i-trudovaya
Что будет, если там появятся новые посты? nginx каким-то образом узнаёт, что контент обновился?
Вот эта страница для анонимуса будет закеширована на час? www.hr-portal.ru/forum/ispytatelnyi-srok-i-trudovaya
Что будет, если там появятся новые посты? nginx каким-то образом узнаёт, что контент обновился?
никак не узнает, будет показывать не обновленную страницу
модуля никакого не надо писать, мне кажется у друпала и так что-то в куки пишется при авторизации, еще одну лишнюю заводить — лишний трафик на сервер
модуля никакого не надо писать, мне кажется у друпала и так что-то в куки пишется при авторизации, еще одну лишнюю заводить — лишний трафик на сервер
Друпал пишет сессию, причем и анонимам. Так что универсально — только через куку.
А вы не обращали внимание, что у залогиненых есть кука DRUPAL_UID?
эту куку выставляет cacherouter
он не входит в поставку Drupal 6
он не входит в поставку Drupal 6
Ну так получается, что cacherouter полезней поставить чем ваш модуль…
если используются другие его возможности :)
а если его ставить только для выставления куки — то вреднее
а если его ставить только для выставления куки — то вреднее
вы хоть приблизительно представляете себе во сколько раз на пустом месте ускоряет cacherouter? какой же смысл отказываться от него? =)
на пустом месте cacherouter ускоряет ровно в 1 раз. если его поставить для установки куки DRUPAL_UID.
напомню, ветка именно об этом. вы утверждали, что у залогиненных есть кука DRUAPL_UID, а ее нет.
напомню, ветка именно об этом. вы утверждали, что у залогиненных есть кука DRUAPL_UID, а ее нет.
на пустом месте cacherouter ускоряет ровно в 1 раз
Не преувеличивайте. Никто ТОЛЬКО ради куки такой модуль ставить не будет. Опять же в чем проблема, если куку ставит этот модуль, а не ваш? Для вашего решения с nginx это одинаково, но cacherouter ускоряет drupal в любом случае по сравнению с вашим модулем.
вы утверждали, что у залогиненных есть кука DRUAPL_UID, а ее нет.
вы правы, я давно не запускал друпал без cacherouter.
А чем плох модуль boost? Он делает примерно тоже самое: отдает кеш анонимам минуя Друпал, только кеш хранится в файловой системе, а не в оперативной памяти (я ведь правильно понимаю, что кеш энжиникса находится в RAM?). Судя по логам, у нас страницы Апачем отдаются энжиниксу за 5-10 милисекунд. Только вот у буста нет описанной выше проблемы: его можно настроить так, что при обновлении страницы сбрасывался её кеш.
Тем, что nginx не отдаст запрос в php и система будет меньше жрать ресурсов?
boost настраивает точно так же на статическое кеширование самим nginx, только механизм кеширования другой. php для очистки кеша вызывается по cron
С бустом также: в .htaccess прописывается блок правил, который по куке проверяет является пользователь анонимом или нет, если является, то запрошенный УРЛ ищется в файловом кеше, и только если в кеше нет файла, то тогда дергается php + Drupal. Если файл с закешированной страницей в кеше есть, то Апач отдает его не вызывая никаких php-скриптов.
И смысл, если можно сделать так, что до апачей запрос вообще не дойдёт?
Смысл описал в ветке комментариев ниже.
Комментарий не по делу. Если фронтендом стоит nginx, то апач просто лишнее звено. rrromka имел в виду, что boost делает всё для того, чтобы кешем пользовался фронтенд, будь то apache или nginx, без обращения к php.
ответ достаточно сложен. попробую объяснить :)
Начнем с того, что как вы верно заметили — мое решение не коробочное, и оно должно применяться, когда посещаемость действительно высока — и любые способы повышения производительности важны.
1. nginx-фронтэнд может находиться на отдельном сервере — кэш будет лежать там же — и отдаваться значительно быстрее
2. nginx в любом случае быстрее отдает статику
3. Drupal может стоять на nginx — в этом случае надо переделывать реврайты boost — оно надо?
4. В случае с boost задача кэширования отдается на бекэнд — этого можно избежать
Начнем с того, что как вы верно заметили — мое решение не коробочное, и оно должно применяться, когда посещаемость действительно высока — и любые способы повышения производительности важны.
1. nginx-фронтэнд может находиться на отдельном сервере — кэш будет лежать там же — и отдаваться значительно быстрее
2. nginx в любом случае быстрее отдает статику
3. Drupal может стоять на nginx — в этом случае надо переделывать реврайты boost — оно надо?
4. В случае с boost задача кэширования отдается на бекэнд — этого можно избежать
апач обычно вместе с nginx используется и по-этому не имеет проблем с отдачей готового контента, и переписывать реврайты не надо
1. nginx-фронтэнд может находиться на отдельном сервере — кэш будет лежать там же — и отдаваться значительно быстрее
Я писал выше, что Апач отдает энжиниксу страницу закешированную бустом за 5-10 милисекунд. Не такая уж и критичная задержка, но при этом буст значительно более гибок в настройке.
2. nginx в любом случае быстрее отдает статику
Как это связано с кешем? У нас в проекте тоже nginx отдает статику (css, js, картинки).
3. Drupal может стоять на nginx — в этом случае надо переделывать реврайты boost — оно надо?
Либо ставить за nginx'ом апач и есть большой вопрос что будет работать шустрее nginx + Drupal без буста или nginx + Apache + Drupal + boost, уж очень много на это влияет факторов.
4. В случае с boost задача кэширования отдается на бекэнд — этого можно избежать
Зачем этого избегать? В любом случае один раз Друпалу придется сгенерировать страницу для анонима, а потом уже почти без разницы кто эту страницу закеширует и отдаст другому анониму.
мое решение не коробочное, и оно должно применяться, когда посещаемость действительно высока
У нас связка nginx + Apache + Drupal + boost держит нагрузку более миллиона хитов в сутки (для сайта на Друпале это неплохо) и, судя по мониторингу, выдержит и сильно бОльшую нагрузку.
Я писал выше, что Апач отдает энжиниксу страницу закешированную бустом за 5-10 милисекунд. Не такая уж и критичная задержка, но при этом буст значительно более гибок в настройке.
2. nginx в любом случае быстрее отдает статику
Как это связано с кешем? У нас в проекте тоже nginx отдает статику (css, js, картинки).
3. Drupal может стоять на nginx — в этом случае надо переделывать реврайты boost — оно надо?
Либо ставить за nginx'ом апач и есть большой вопрос что будет работать шустрее nginx + Drupal без буста или nginx + Apache + Drupal + boost, уж очень много на это влияет факторов.
4. В случае с boost задача кэширования отдается на бекэнд — этого можно избежать
Зачем этого избегать? В любом случае один раз Друпалу придется сгенерировать страницу для анонима, а потом уже почти без разницы кто эту страницу закеширует и отдаст другому анониму.
мое решение не коробочное, и оно должно применяться, когда посещаемость действительно высока
У нас связка nginx + Apache + Drupal + boost держит нагрузку более миллиона хитов в сутки (для сайта на Друпале это неплохо) и, судя по мониторингу, выдержит и сильно бОльшую нагрузку.
1. Вы немного не поняли. Если фронтэнд находится на отдельном сервере от бекэнда(как у нас допустим) — nginx придется обращаться по сети к другому серверу за кэшем. Зачем?
2. Кэш отдается на фронте, а не на бэке. Это быстрее в любом случае.
3. Drupal + nginx. Никак факторов в пользу второй связки нет.
4. Разница в любом случае есть. Если для производительности ваших проектов она не критична — это вопрос другой.
2. Кэш отдается на фронте, а не на бэке. Это быстрее в любом случае.
3. Drupal + nginx. Никак факторов в пользу второй связки нет.
4. Разница в любом случае есть. Если для производительности ваших проектов она не критична — это вопрос другой.
1. Вы немного не поняли. Если фронтэнд находится на отдельном сервере от бекэнда(как у нас допустим) — nginx придется обращаться по сети к другому серверу за кэшем.
У нас тоже.
Зачем?
Затем, что можно получить более гибкий кеш, обновляемый вместе с обновлением контента, а не по таймеру.
2. Кэш отдается на фронте, а не на бэке. Это быстрее в любом случае.
В очередной раз повторю. В таком случае если у вас обновился материал, добавились комментарии или, например, обновился какой-то блок (это может быть очень важно для новостных сайтов, когда появляется по 10 новых новостей в час и на каждой из страниц выводится блок с последними новостями), то анонимы всех этих обновлений не увидят до очистки кеша.
3. Drupal + nginx. Никак факторов в пользу второй связки нет.
4. Разница в любом случае есть. Если для производительности ваших проектов она не критична — это вопрос другой.
Это ваше предположение или вы проводили тесты? Если предположение, то оно абсолютно не конструктивно. Если были тесты, то было бы интересно увидеть их условия и результаты.
У нас тоже.
Зачем?
Затем, что можно получить более гибкий кеш, обновляемый вместе с обновлением контента, а не по таймеру.
2. Кэш отдается на фронте, а не на бэке. Это быстрее в любом случае.
В очередной раз повторю. В таком случае если у вас обновился материал, добавились комментарии или, например, обновился какой-то блок (это может быть очень важно для новостных сайтов, когда появляется по 10 новых новостей в час и на каждой из страниц выводится блок с последними новостями), то анонимы всех этих обновлений не увидят до очистки кеша.
3. Drupal + nginx. Никак факторов в пользу второй связки нет.
4. Разница в любом случае есть. Если для производительности ваших проектов она не критична — это вопрос другой.
Это ваше предположение или вы проводили тесты? Если предположение, то оно абсолютно не конструктивно. Если были тесты, то было бы интересно увидеть их условия и результаты.
1. Вопрос решается практически копипастом куска модуля boost в свой. Как я уже говорил, мы это обязательно сделаем.
2. Важность сомнительна. Если пользователю так интересен сайт — он, наверно, авторизуется и будет получать все в обход кэша. Впрочем, это решаемо в пункте 1, причем весьма тривиально.
3+4. Даже предположение вполне конструктивно. Как минимум есть разница в сетевых издержках между фронтэндом и бекэндом, вы же не будете это отрицать?
Так или иначе предлагаю соревнование :) Я на следующем друпалкемпе приведу в презентации сравнение этих методов на основе тестов. Ставка — литр виски :) А до той поры дискуссию отложим.
2. Важность сомнительна. Если пользователю так интересен сайт — он, наверно, авторизуется и будет получать все в обход кэша. Впрочем, это решаемо в пункте 1, причем весьма тривиально.
3+4. Даже предположение вполне конструктивно. Как минимум есть разница в сетевых издержках между фронтэндом и бекэндом, вы же не будете это отрицать?
Так или иначе предлагаю соревнование :) Я на следующем друпалкемпе приведу в презентации сравнение этих методов на основе тестов. Ставка — литр виски :) А до той поры дискуссию отложим.
2. Как причастный к новостным сайтам авторитетно заявляю, что пользователи ненавидят на них регистрироваться и логиниться. Да и серверу легче от кеша, чем от перегенерации под зарегистрированных. Кстати в drupal.org/project/authcache очень оригинальный подход к ролевому кешу — никнейм и адрес личной страницы грузятся через ajax, а страница для всех пользователей одной роли кеширована. Советую присмотреться для улучшения вашего функционала.
Так или иначе предлагаю соревнование :) Я на следующем друпалкемпе приведу в презентации сравнение этих методов на основе тестов. Ставка — литр виски :) А до той поры дискуссию отложим.
Ок, договорились. Речь о кемпе в Киеве? В Москве с кемпами как-то тухло. Правда непонятно как будут проводиться замеры…
2. Важность сомнительна.
Для проекта над которым работаю я наличие обновляемого по запросу кеша имеет максимальную важность.
Если пользователю так интересен сайт — он, наверно, авторизуется и будет получать все в обход кэша.
Пользователю интересен не сайт, а новость. Если он её не увидел, то он уйдет на другой сайт. Иногда, совсем редко, возникают экстраординарные события, которые вызывают огромный интерес у посетителей и информация о которых обновляется чуть ли не каждые 5 минут. В такие моменты посещаемость новостных сайтов увеличивается в разы. Для таких ситуаций кеш на час — это беда.
Кроме того важно забывать про поисковики, которые тоже индексируют сайты под анонимом. В вашем случае вполне велика вероятность того, что вы опубликуете новость раньше конкурентов, но из-за кеша в поисковик она попадет позже и, как следствие, поисковик (или новостной агрегатор) в выдаче поставит ссылки не на вас.
Ок, договорились. Речь о кемпе в Киеве? В Москве с кемпами как-то тухло. Правда непонятно как будут проводиться замеры…
2. Важность сомнительна.
Для проекта над которым работаю я наличие обновляемого по запросу кеша имеет максимальную важность.
Если пользователю так интересен сайт — он, наверно, авторизуется и будет получать все в обход кэша.
Пользователю интересен не сайт, а новость. Если он её не увидел, то он уйдет на другой сайт. Иногда, совсем редко, возникают экстраординарные события, которые вызывают огромный интерес у посетителей и информация о которых обновляется чуть ли не каждые 5 минут. В такие моменты посещаемость новостных сайтов увеличивается в разы. Для таких ситуаций кеш на час — это беда.
Кроме того важно забывать про поисковики, которые тоже индексируют сайты под анонимом. В вашем случае вполне велика вероятность того, что вы опубликуете новость раньше конкурентов, но из-за кеша в поисковик она попадет позже и, как следствие, поисковик (или новостной агрегатор) в выдаче поставит ссылки не на вас.
По поводу кемпа — я очень надеюсь что при нашей поддержке он пройдет в Москве в феврале-марте.
По поводу замеров — можем сделать все по взрослому. Взять сайт с несколькими десятками тысяч нод, возьмем HP LoadRunner и погоняем его. А потом посмотрим аналитику.
По поводу замеров — можем сделать все по взрослому. Взять сайт с несколькими десятками тысяч нод, возьмем HP LoadRunner и погоняем его. А потом посмотрим аналитику.
Соревнование не корректно в контексте 1 часа кеша. Новостные сайты с редко позволяют себе делать кеш даже на 5 минут, чаще — 1 минута. На выборке в 50 тысяч нод с реальным разбросом пользователей по нодам ваш 10 мб кеш будет задействован на 40-50%, вряд ли больше. Так что на реальной новостной аудитории вашему методу предпочтительнее связка memcached + cacherouter + authcache. Куском boost и кешем nginx вы ее к сожалению не замените.
вы запутались похоже.
1) authcache можно применять и при кэшировании nginx и при cacherouter + memcache.
разница в производительности без тестов не очевидно.
2) сравнивать на тестах мы будем технологии кэширования, которые не предусматривают задержек, в том числе и кэширование с использованием nginx
1) authcache можно применять и при кэшировании nginx и при cacherouter + memcache.
разница в производительности без тестов не очевидно.
2) сравнивать на тестах мы будем технологии кэширования, которые не предусматривают задержек, в том числе и кэширование с использованием nginx
1. наслоение кешей одного уровня это бессмысленный анонизм. А при одновременном authcache и nginx теряется контроль за актуальностью данных.
2. Вы предлагаете сэкономить производительность отказавшись от динамичности. Для сферического коня в вакууме разница в скорости работы кешей nginx и cacherouter всегда на стороне nginx, но для реального новостного сайта условия не такие:
— пользователи переписываются в комментариях, ведут там такие же интерактивные дискуссии, как и мы тут с вами. И анонимные намного активнее! Предлагаете отказать им в этих возможностях ради красоты вашего решения?
— все активные ноды не помещаются ни в памяти ни в кеше за раз, если это настоящий серьезный проект.
— обновления некоторых блоков требует полного сброса кеша в конкретную минуту времени. В какой-то момент ваш механизм актуализации кеша будет больше заниматься удалением файлов, чем их выдачей пользователям. (я с этим уже экспериментировал)
— чем выручает cacherouter, так это независимым кешированием блоков, которое дает обойтись малой кровью при сборке страниц, даже для последующего кеширования.
— пытаясь обойтись без cacherouter одним кешем nginx в таких условиях вы рискуете проиграть в производительности за счет многочисленных обращений к базе за кешем(!).
Не сочтите за грубость, но я отлично понимаю что и почему вы имеете в виду, поскольку сам так расставлял приоритеты, пока не встрял в реальный новостной проект. Тут нельзя сказать, «пусть логинятся если хотят актуальности», как говорите вы. Тут невозможно закладываться на то, что 100 одновременных авторизованных пользователей могут потерпеть полного рендеринга 100 разных страниц одновременно и обновить страницу если будет таймаут. Задача в том, чтобы никакая страница не рендерилась больше 400 мсек, иначе начнется лавина таймаутов. Критически важно для конкуренции, чтобы никакая информация не задержалась более, чем на несколько секунд. Тут не до теоретизирования «что быстрее выстреливает кешированную страницу php или nginx». Вот в чем я вижу некорректность вашего спора.
2. Вы предлагаете сэкономить производительность отказавшись от динамичности. Для сферического коня в вакууме разница в скорости работы кешей nginx и cacherouter всегда на стороне nginx, но для реального новостного сайта условия не такие:
— пользователи переписываются в комментариях, ведут там такие же интерактивные дискуссии, как и мы тут с вами. И анонимные намного активнее! Предлагаете отказать им в этих возможностях ради красоты вашего решения?
— все активные ноды не помещаются ни в памяти ни в кеше за раз, если это настоящий серьезный проект.
— обновления некоторых блоков требует полного сброса кеша в конкретную минуту времени. В какой-то момент ваш механизм актуализации кеша будет больше заниматься удалением файлов, чем их выдачей пользователям. (я с этим уже экспериментировал)
— чем выручает cacherouter, так это независимым кешированием блоков, которое дает обойтись малой кровью при сборке страниц, даже для последующего кеширования.
— пытаясь обойтись без cacherouter одним кешем nginx в таких условиях вы рискуете проиграть в производительности за счет многочисленных обращений к базе за кешем(!).
Не сочтите за грубость, но я отлично понимаю что и почему вы имеете в виду, поскольку сам так расставлял приоритеты, пока не встрял в реальный новостной проект. Тут нельзя сказать, «пусть логинятся если хотят актуальности», как говорите вы. Тут невозможно закладываться на то, что 100 одновременных авторизованных пользователей могут потерпеть полного рендеринга 100 разных страниц одновременно и обновить страницу если будет таймаут. Задача в том, чтобы никакая страница не рендерилась больше 400 мсек, иначе начнется лавина таймаутов. Критически важно для конкуренции, чтобы никакая информация не задержалась более, чем на несколько секунд. Тут не до теоретизирования «что быстрее выстреливает кешированную страницу php или nginx». Вот в чем я вижу некорректность вашего спора.
ужас какой.
не теряется ни разу. хук на коммент, который дропает кэш ноды — и проблема решена
ни разу. еще раз — хук на коммент, который дропает кэш — проблема решена
каких блоков и при чем тут именно cacherouter?
nginx cache хранить в базе только индекс кэша. все страницы лежат в файловой системе. в оперативную память попадают только те файлы, к которым часто обращаются — так работает кэш ОС
а вашего в том, что вы мешаете в кучу идею и технологии
идея — сделать всегда актуальный кэш, сбрасывая кэш ноды при каждом ее изменении или появлении комментария, а так же сбрасывать кэш страниц списков при появлении новых нод в них
nginx cache — кэш на фронте, может хранить в файловой системе странички, отдельно для зарегенных и анонимных пользователей
boost — модуль Drupal, который добавляет реврайты в веб сервер, при помощи которых отдает странички с файловой системы
cacherouter — интерфейс к разным бекэндам кэширования
authcache — модуль, который позволяет на стороне клиента с помощью ajax запросов подменить часть html кода.
как после этого понимать ваши фразы типа
В моем решении никто не мешает включить authcache, при этом все странички отдавать из кэша nginx с тем, чтобы js на стороне клиента дальше подменял блоки, обращаясь к php.
А при одновременном authcache и nginx теряется контроль за актуальностью данных.
не теряется ни разу. хук на коммент, который дропает кэш ноды — и проблема решена
пользователи переписываются в комментариях, ведут там такие же интерактивные дискуссии, как и мы тут с вами. И анонимные намного активнее! Предлагаете отказать им в этих возможностях ради красоты вашего решения?
ни разу. еще раз — хук на коммент, который дропает кэш — проблема решена
чем выручает cacherouter, так это независимым кешированием блоков, которое дает обойтись малой кровью при сборке страниц, даже для последующего кеширования
каких блоков и при чем тут именно cacherouter?
пытаясь обойтись без cacherouter одним кешем nginx в таких условиях вы рискуете проиграть в производительности за счет многочисленных обращений к базе за кешем
nginx cache хранить в базе только индекс кэша. все страницы лежат в файловой системе. в оперативную память попадают только те файлы, к которым часто обращаются — так работает кэш ОС
Вот в чем я вижу некорректность вашего спора
а вашего в том, что вы мешаете в кучу идею и технологии
идея — сделать всегда актуальный кэш, сбрасывая кэш ноды при каждом ее изменении или появлении комментария, а так же сбрасывать кэш страниц списков при появлении новых нод в них
nginx cache — кэш на фронте, может хранить в файловой системе странички, отдельно для зарегенных и анонимных пользователей
boost — модуль Drupal, который добавляет реврайты в веб сервер, при помощи которых отдает странички с файловой системы
cacherouter — интерфейс к разным бекэндам кэширования
authcache — модуль, который позволяет на стороне клиента с помощью ajax запросов подменить часть html кода.
как после этого понимать ваши фразы типа
при одновременном authcache и nginx
пытаясь обойтись без cacherouter одним кешем nginx
В моем решении никто не мешает включить authcache, при этом все странички отдавать из кэша nginx с тем, чтобы js на стороне клиента дальше подменял блоки, обращаясь к php.
Вас можно попросить вести себя не так высокомерно? Вам сразу станет понятно что я пишу. Попробуйте для начала принять, что я разбираюсь в этих вопросах не хуже вас и просто имею другой взгляд на те же знания. А теперь попунктно:
если было бы возможно так легко отделаться, то я бы не стал с вами спорить, а давно бы так и закодил. Однако кеш страницы во многих случаях нужно сбрасывать не только при изменении нода и комментариев, но и при изменении блоков, которые выведены на эту страницу. В случае новостных, например, у меня на странице новости расположены блоки со списками последних новостей тех рубрик, в которые входит эта новость. И блок с последними комментариями ко всем страницам. Это важнейший элемент юзабилити конкретного сайта. Вы уже представили себе механизм, позволяющий обновлять эти блоки дешевле, чем перегенерация страницы? (про недостаток ajax-решения напишу ниже)
по переписке в комментариях
вы не рассмотрели описанную мною вероятность появления нагрузки за счет механизма «дропанья кеша», а зря. Но надеюсь вы найдете время проверить это в максимально реалистичных условиях.
Какую по-вашему роль он выполняет? Только кеширует страницы? Если так, то советую рассмотреть и остальной его функционал, а именно — замену всего механизма кеширования drupal (который основан на RDBMS) на более дешевые — кеш в памяти, модулях php и на диске. Вы удивитесь насколько это ускоряет рендеринг страниц.
Я говорил о вашей SQL базе, из которой берутся ноды, блоки и формы для рендеринга страниц пока не поставишь cacherouter.
Идея очевидная, но конкурентного преимущества не дает. Нужно обновлять страницы еще по множеству поводов. Но самое главное — надо избежать торможения даже на первичной генерации страниц для кеша. И потому, что каждый запрос важен и потому, что кеш будет очищаться часто. Так что облегчать работу для бэкэнда надо обязательно, чему и служат cacherouter с authcache
Уверен, вы знакомы с поисковой оптимизацией. Отдавать блоки со списками статей, релевантных текущему ноду при помощи ajax это очень большая ошибка. Можно обновлять на странице через ajax что угодно, но отдавать html анонимному посетителю, а значит и поисковику надо вместе со всеми релевантными ссылками. Думаю вам дальше понятен ход моих мыслей.
не теряется ни разу. хук на коммент, который дропает кэш ноды — и проблема решена
если было бы возможно так легко отделаться, то я бы не стал с вами спорить, а давно бы так и закодил. Однако кеш страницы во многих случаях нужно сбрасывать не только при изменении нода и комментариев, но и при изменении блоков, которые выведены на эту страницу. В случае новостных, например, у меня на странице новости расположены блоки со списками последних новостей тех рубрик, в которые входит эта новость. И блок с последними комментариями ко всем страницам. Это важнейший элемент юзабилити конкретного сайта. Вы уже представили себе механизм, позволяющий обновлять эти блоки дешевле, чем перегенерация страницы? (про недостаток ajax-решения напишу ниже)
по переписке в комментариях
хук на коммент, который дропает кэш — проблема решена
вы не рассмотрели описанную мною вероятность появления нагрузки за счет механизма «дропанья кеша», а зря. Но надеюсь вы найдете время проверить это в максимально реалистичных условиях.
каких блоков и при чем тут именно cacherouter?
Какую по-вашему роль он выполняет? Только кеширует страницы? Если так, то советую рассмотреть и остальной его функционал, а именно — замену всего механизма кеширования drupal (который основан на RDBMS) на более дешевые — кеш в памяти, модулях php и на диске. Вы удивитесь насколько это ускоряет рендеринг страниц.
пытаясь обойтись без cacherouter одним кешем nginx в таких условиях вы рискуете проиграть в производительности за счет многочисленных обращений к базе за кешем
nginx cache хранить в базе только индекс кэша. все страницы лежат в файловой системе. в оперативную память попадают только те файлы, к которым часто обращаются — так работает кэш ОС
Я говорил о вашей SQL базе, из которой берутся ноды, блоки и формы для рендеринга страниц пока не поставишь cacherouter.
идея — сделать всегда актуальный кэш, сбрасывая кэш ноды при каждом ее изменении или появлении комментария, а так же сбрасывать кэш страниц списков при появлении новых нод в них
Идея очевидная, но конкурентного преимущества не дает. Нужно обновлять страницы еще по множеству поводов. Но самое главное — надо избежать торможения даже на первичной генерации страниц для кеша. И потому, что каждый запрос важен и потому, что кеш будет очищаться часто. Так что облегчать работу для бэкэнда надо обязательно, чему и служат cacherouter с authcache
В моем решении никто не мешает включить authcache, при этом все странички отдавать из кэша nginx с тем, чтобы js на стороне клиента дальше подменял блоки, обращаясь к php.
Уверен, вы знакомы с поисковой оптимизацией. Отдавать блоки со списками статей, релевантных текущему ноду при помощи ajax это очень большая ошибка. Можно обновлять на странице через ajax что угодно, но отдавать html анонимному посетителю, а значит и поисковику надо вместе со всеми релевантными ссылками. Думаю вам дальше понятен ход моих мыслей.
мне кажется, вы слишком мнительны. никто не ведет себя высокомерно, это скорее вы проявляете неуместную напористость менеджера Microsoft, пытаясь объявить свое решение единственно верным — и почему-то исключающем другие решения.
при этом вы слишком мало владеете предметом и слишком невнимательно следите за собеседником. как можно с вами общаться, если на
вы мне отвечаете
Что я могу ответить? Спасибо, кэп, что перечислили разные бекэнды кэширования — memcache, apc,…
Никакой излишней нагрузки из-за дропанья кэша страницы не будет, я вас уверяю. Это дропанье так и так происходит, а в приведенном решении авторизованные пользователи ходят в обход кэша nginx.
по поводу ajax — authcache работает только через него drupal.org/node/394840
однако по дефолту он подгружает только данные, относящиеся к текущему авторизованному пользователю, что не имеет никакого отношения к seo.
по поводу разных блоков для ноды — учитывая, что rromka использует boost — и зная, что за сайт он представляет, могу заверить вас, что эта проблема высосана из пальца специально для этой дискуссии. если не согласны — урл, где это актуально.
при этом вы слишком мало владеете предметом и слишком невнимательно следите за собеседником. как можно с вами общаться, если на
cacherouter — интерфейс к разным бекэндам кэширования
вы мне отвечаете
Какую по-вашему роль он выполняет? Только кеширует страницы? Если так, то советую рассмотреть и остальной его функционал, а именно — замену всего механизма кеширования drupal (который основан на RDBMS) на более дешевые — кеш в памяти, модулях php и на диске. Вы удивитесь насколько это ускоряет рендеринг страниц.
Что я могу ответить? Спасибо, кэп, что перечислили разные бекэнды кэширования — memcache, apc,…
Никакой излишней нагрузки из-за дропанья кэша страницы не будет, я вас уверяю. Это дропанье так и так происходит, а в приведенном решении авторизованные пользователи ходят в обход кэша nginx.
по поводу ajax — authcache работает только через него drupal.org/node/394840
однако по дефолту он подгружает только данные, относящиеся к текущему авторизованному пользователю, что не имеет никакого отношения к seo.
по поводу разных блоков для ноды — учитывая, что rromka использует boost — и зная, что за сайт он представляет, могу заверить вас, что эта проблема высосана из пальца специально для этой дискуссии. если не согласны — урл, где это актуально.
Под последними двумя абзацами подпишусь двумя руками!!!
3. Это давно сделано drupal.org/node/244072
4. И в кеш попадут страницы /node/10?keys=asdf наряду с /node/10. Как вы можете проконтролировать все варианты url для одной страницы, закешированной самим nginx? boost это делает на php.
4. И в кеш попадут страницы /node/10?keys=asdf наряду с /node/10. Как вы можете проконтролировать все варианты url для одной страницы, закешированной самим nginx? boost это делает на php.
по поводу пункта 4 — и при помощи boost и при помощи nginx cache это будут совершенно разные страницы. непонятно, что вы эти хотите сказать.
Я хочу сказать, что /node/10?keys=asdf часто совпадает с /node/10 по содержанию.
1. Если вы хотите встроить в Drupal механизм очистки кеша, то учитывать вам нужно все разные url одной страницы, не так ли?
2. Если вы не хотите давать врагам возможность досить ваш кеш и механизм кеширования, лучше бы иметь инструмент очистки кеша от паразитных url
1. Если вы хотите встроить в Drupal механизм очистки кеша, то учитывать вам нужно все разные url одной страницы, не так ли?
2. Если вы не хотите давать врагам возможность досить ваш кеш и механизм кеширования, лучше бы иметь инструмент очистки кеша от паразитных url
Global Redirect?
Неа, не решит проблему =)
Да и делается он бекендом после bootstrap. Где уж тут выигрыш в производительности перед boost?
Да и делается он бекендом после bootstrap. Где уж тут выигрыш в производительности перед boost?
Global Redirect выполняет редиректы, а не реврайты. Поэтому проблему мусорных урлов он должен решить.
Увы, не до конца. Не хочу вдаваться в детали, но «отравить» мусором кеш nginx с вашими настройками он не помешает.
Даже если так, у нас есть inactive timeout. Мусор не сможет выдавить из кэша часто посещаемые странички.
Если это случайный мусор, то не сможет, но если конкурент взялся вас «наказывать», то не сложно свести на нет преимущества вашего механизма кеширования, как раз забивая кеш на время inactive timeout страницами, которые ваш актуализатор кеша не сможет найти.
… кроме того, каждая такая страница будет браться не из кеша, то есть нагружать бэкенд. Я недавно как раз попал под такую атаку, имел возможность поиграться в защиту кеша. Победил кстати редиректами на стороне nginx. =)
Не узнает, страница для анонима обновится только через час.
Однако есть простое решение — мы его допишем и выложим. Если вкратце, то необходимо повесить хук на добавление комментария или изменение ноды, который удаляет соответствующий файл из кэша. Файл найти просто — md5 от ключа из конфига.
Такой метод Игорь Сысоев одобряет.
Однако есть простое решение — мы его допишем и выложим. Если вкратце, то необходимо повесить хук на добавление комментария или изменение ноды, который удаляет соответствующий файл из кэша. Файл найти просто — md5 от ключа из конфига.
Такой метод Игорь Сысоев одобряет.
это конфиг для апача, стоящего за nginx?
а как насчёт подобного решения, но для связки nginx+php-fpm?
а как насчёт подобного решения, но для связки nginx+php-fpm?
да, данный конфиг nginx используется если бекэнд — вебсервер.
как верно замечено по ссылке selfchief, нужно заменить в конфиге proxy_ на fastcgi_, вставить несколько переменных — и все будет работать.
как верно замечено по ссылке selfchief, нужно заменить в конфиге proxy_ на fastcgi_, вставить несколько переменных — и все будет работать.
спасибо, попробуем.
а есть какие-нибудь сравнения производительности этого решения против обычного друпалево кеширования?
а есть какие-нибудь сравнения производительности этого решения против обычного друпалево кеширования?
со встроенным кэшированием сравнивать смысла — встроенное слишком уныло:
www.metaltoad.com/blog/quick-drupal-cacherouter-and-boost-benchmarks
по вышеописанному методу — детальное сравнение буду готовить только к следующему DrupalCamp. Могу лишь сказать, что для анонимных пользователей нагрузка фактически ограничивается ресурсами сервера и перестает зависеть от Друпала. Сайт практически аналогичен набору html страниц.
www.metaltoad.com/blog/quick-drupal-cacherouter-and-boost-benchmarks
по вышеописанному методу — детальное сравнение буду готовить только к следующему DrupalCamp. Могу лишь сказать, что для анонимных пользователей нагрузка фактически ограничивается ресурсами сервера и перестает зависеть от Друпала. Сайт практически аналогичен набору html страниц.
Обращу внимание, что если используются сессии, то надо добавить в fastcgi_ignore_headers — Set-Cookie, иначе не будет кешировать
Поздравляю, но не велико достижение тупо писать страницы в статические файлы. Главная задача — обновлять нужные кэши при изменении соответствующих объектов (как сделано у нас). Справитесь с этим — честь вам и хвала.
>как сделано у нас
Так расскажите лучше как это сделано у вас? Была бы и вам — честь и хвала.
Так расскажите лучше как это сделано у вас? Была бы и вам — честь и хвала.
а в чем хвала? понятно, что лучше вывешивать всегда актуальную информацию, однако 1 час — не такая уж большая потеря в актуальности для многих проектов.
и да, может быть действительно расскажете? :)
и да, может быть действительно расскажете? :)
Я конечно не он, но оптимизировал как раз новостные сайты на drupal. Могу предложить ознакомиться с drupal.org/project/authcache. В связке с memcached по опыту дает неплохие результаты для сайтов с высокой степенью обновляемости.
Какая посещаемость сейчас у госбука?
Пробивание по опен-стату ничего не дало (openstat.ru), нетчарт по этому сайту почему-то статистику не кажет (netchart.ru).
В моем круге у вас написано «кластеризация госбук», но в таком случае счет должен идти на десятки тысяч посетителей в день, так?
Пробивание по опен-стату ничего не дало (openstat.ru), нетчарт по этому сайту почему-то статистику не кажет (netchart.ru).
В моем круге у вас написано «кластеризация госбук», но в таком случае счет должен идти на десятки тысяч посетителей в день, так?
Рекомендую рассмотреть следующее решение, которое будем пользовать мы:
1. кэш nginx лежит в memcache, но т.к. nginx не умеет сам писать в memcache…
2. делаем модуль к CMS, который кладет в memcache страницы для анонимусов, и обновляет их по мере добавления контента зарегистрированными.
Таким образом, закэшированная страница для анонимуса будет получаться без запроса бэкенда, и при этом будет всегда актуальная.
1. кэш nginx лежит в memcache, но т.к. nginx не умеет сам писать в memcache…
2. делаем модуль к CMS, который кладет в memcache страницы для анонимусов, и обновляет их по мере добавления контента зарегистрированными.
Таким образом, закэшированная страница для анонимуса будет получаться без запроса бэкенда, и при этом будет всегда актуальная.
Классно, мы думаем об этом, можно даже использовать SSI в nginx habrahabr.ru/blogs/hi/109050/
Интересный подход. Он уже где-то реализован или пока есть только в теории? Было бы интересно почитать статью отчет о внедрении подобной системы.
Есть уже решение — описано тут groups.drupal.org/node/26363
смотрите камменты и ссылка на полный конфиг nginx github.com/omega8cc/nginx-for-drupal
там к примеру не кешируют капчу и файлы json и кое-что патчить нужно в друпале
смотрите камменты и ссылка на полный конфиг nginx github.com/omega8cc/nginx-for-drupal
там к примеру не кешируют капчу и файлы json и кое-что патчить нужно в друпале
На самом деле, есть еще один вариант —
вместо Drupal использовать Pressflow — там уже есть встроенная поддержка кеширующего реверс-прокси (выставляется как External cache в настройках и кое-что правится в settings.php). Вместо куки, имхо, используется более правильный вариант с заголовками Cache-control: public, max-age=… Который nginx должен понимать… (по крайней мере Varnish отлично понимает).
Правда, чтобы кеширующий прокси отрабатывал на ура с помощью заголовков, надо для анонимусов поотрубать все куки, которые могут выставлять разные модули, т.к. идет отсылка заголовка Vary: cookie, что может расстроить верную работу кешинга. :) Не всегда можно отковырять куки, т.к. часто нужны разные джаваскриптовые и гугловские куки, которые можно отрезать на самом прокси, непосредственно перед анализом заголовков самим прокси (кешировать или нет). Это легко делается в Varnish'е, а вот насчет nginx не уверен.
Вообще если нужен только кешинг или load-balancing, то Varnish имхо более продвинутая и интересная тулза чем кешинг в nginx. Правда т.к. он более продвинут, то и конфиги там более злые, но если разобраться, то все кажется симпатичным. :) С Varnish'ем идет также много полезных утилит для анализа работы кешинга.
вместо Drupal использовать Pressflow — там уже есть встроенная поддержка кеширующего реверс-прокси (выставляется как External cache в настройках и кое-что правится в settings.php). Вместо куки, имхо, используется более правильный вариант с заголовками Cache-control: public, max-age=… Который nginx должен понимать… (по крайней мере Varnish отлично понимает).
Правда, чтобы кеширующий прокси отрабатывал на ура с помощью заголовков, надо для анонимусов поотрубать все куки, которые могут выставлять разные модули, т.к. идет отсылка заголовка Vary: cookie, что может расстроить верную работу кешинга. :) Не всегда можно отковырять куки, т.к. часто нужны разные джаваскриптовые и гугловские куки, которые можно отрезать на самом прокси, непосредственно перед анализом заголовков самим прокси (кешировать или нет). Это легко делается в Varnish'е, а вот насчет nginx не уверен.
Вообще если нужен только кешинг или load-balancing, то Varnish имхо более продвинутая и интересная тулза чем кешинг в nginx. Правда т.к. он более продвинут, то и конфиги там более злые, но если разобраться, то все кажется симпатичным. :) С Varnish'ем идет также много полезных утилит для анализа работы кешинга.
Sign up to leave a comment.
Кэширование nginx для анонимных пользователей на примере Drupal