… кроме того, каждая такая страница будет браться не из кеша, то есть нагружать бэкенд. Я недавно как раз попал под такую атаку, имел возможность поиграться в защиту кеша. Победил кстати редиректами на стороне nginx. =)
Если это случайный мусор, то не сможет, но если конкурент взялся вас «наказывать», то не сложно свести на нет преимущества вашего механизма кеширования, как раз забивая кеш на время inactive timeout страницами, которые ваш актуализатор кеша не сможет найти.
Вас можно попросить вести себя не так высокомерно? Вам сразу станет понятно что я пишу. Попробуйте для начала принять, что я разбираюсь в этих вопросах не хуже вас и просто имею другой взгляд на те же знания. А теперь попунктно:
не теряется ни разу. хук на коммент, который дропает кэш ноды — и проблема решена
если было бы возможно так легко отделаться, то я бы не стал с вами спорить, а давно бы так и закодил. Однако кеш страницы во многих случаях нужно сбрасывать не только при изменении нода и комментариев, но и при изменении блоков, которые выведены на эту страницу. В случае новостных, например, у меня на странице новости расположены блоки со списками последних новостей тех рубрик, в которые входит эта новость. И блок с последними комментариями ко всем страницам. Это важнейший элемент юзабилити конкретного сайта. Вы уже представили себе механизм, позволяющий обновлять эти блоки дешевле, чем перегенерация страницы? (про недостаток ajax-решения напишу ниже)
по переписке в комментариях
хук на коммент, который дропает кэш — проблема решена
вы не рассмотрели описанную мною вероятность появления нагрузки за счет механизма «дропанья кеша», а зря. Но надеюсь вы найдете время проверить это в максимально реалистичных условиях.
каких блоков и при чем тут именно cacherouter?
Какую по-вашему роль он выполняет? Только кеширует страницы? Если так, то советую рассмотреть и остальной его функционал, а именно — замену всего механизма кеширования drupal (который основан на RDBMS) на более дешевые — кеш в памяти, модулях php и на диске. Вы удивитесь насколько это ускоряет рендеринг страниц.
пытаясь обойтись без cacherouter одним кешем nginx в таких условиях вы рискуете проиграть в производительности за счет многочисленных обращений к базе за кешем
nginx cache хранить в базе только индекс кэша. все страницы лежат в файловой системе. в оперативную память попадают только те файлы, к которым часто обращаются — так работает кэш ОС
Я говорил о вашей SQL базе, из которой берутся ноды, блоки и формы для рендеринга страниц пока не поставишь cacherouter.
идея — сделать всегда актуальный кэш, сбрасывая кэш ноды при каждом ее изменении или появлении комментария, а так же сбрасывать кэш страниц списков при появлении новых нод в них
Идея очевидная, но конкурентного преимущества не дает. Нужно обновлять страницы еще по множеству поводов. Но самое главное — надо избежать торможения даже на первичной генерации страниц для кеша. И потому, что каждый запрос важен и потому, что кеш будет очищаться часто. Так что облегчать работу для бэкэнда надо обязательно, чему и служат cacherouter с authcache
В моем решении никто не мешает включить authcache, при этом все странички отдавать из кэша nginx с тем, чтобы js на стороне клиента дальше подменял блоки, обращаясь к php.
Уверен, вы знакомы с поисковой оптимизацией. Отдавать блоки со списками статей, релевантных текущему ноду при помощи ajax это очень большая ошибка. Можно обновлять на странице через ajax что угодно, но отдавать html анонимному посетителю, а значит и поисковику надо вместе со всеми релевантными ссылками. Думаю вам дальше понятен ход моих мыслей.
на пустом месте cacherouter ускоряет ровно в 1 раз
Не преувеличивайте. Никто ТОЛЬКО ради куки такой модуль ставить не будет. Опять же в чем проблема, если куку ставит этот модуль, а не ваш? Для вашего решения с nginx это одинаково, но cacherouter ускоряет drupal в любом случае по сравнению с вашим модулем.
вы утверждали, что у залогиненных есть кука DRUAPL_UID, а ее нет.
вы правы, я давно не запускал друпал без cacherouter.
Я как-то пытался сделать это на основе boost. Довести до продакшна не удалось. Новая версия authcache что-то подобное позволяет сделать при небольших допиливаниях, но еще не разбирался с этим.
1. наслоение кешей одного уровня это бессмысленный анонизм. А при одновременном authcache и nginx теряется контроль за актуальностью данных.
2. Вы предлагаете сэкономить производительность отказавшись от динамичности. Для сферического коня в вакууме разница в скорости работы кешей nginx и cacherouter всегда на стороне nginx, но для реального новостного сайта условия не такие:
— пользователи переписываются в комментариях, ведут там такие же интерактивные дискуссии, как и мы тут с вами. И анонимные намного активнее! Предлагаете отказать им в этих возможностях ради красоты вашего решения?
— все активные ноды не помещаются ни в памяти ни в кеше за раз, если это настоящий серьезный проект.
— обновления некоторых блоков требует полного сброса кеша в конкретную минуту времени. В какой-то момент ваш механизм актуализации кеша будет больше заниматься удалением файлов, чем их выдачей пользователям. (я с этим уже экспериментировал)
— чем выручает cacherouter, так это независимым кешированием блоков, которое дает обойтись малой кровью при сборке страниц, даже для последующего кеширования.
— пытаясь обойтись без cacherouter одним кешем nginx в таких условиях вы рискуете проиграть в производительности за счет многочисленных обращений к базе за кешем(!).
Не сочтите за грубость, но я отлично понимаю что и почему вы имеете в виду, поскольку сам так расставлял приоритеты, пока не встрял в реальный новостной проект. Тут нельзя сказать, «пусть логинятся если хотят актуальности», как говорите вы. Тут невозможно закладываться на то, что 100 одновременных авторизованных пользователей могут потерпеть полного рендеринга 100 разных страниц одновременно и обновить страницу если будет таймаут. Задача в том, чтобы никакая страница не рендерилась больше 400 мсек, иначе начнется лавина таймаутов. Критически важно для конкуренции, чтобы никакая информация не задержалась более, чем на несколько секунд. Тут не до теоретизирования «что быстрее выстреливает кешированную страницу php или nginx». Вот в чем я вижу некорректность вашего спора.
Комментарий не по делу. Если фронтендом стоит nginx, то апач просто лишнее звено. rrromka имел в виду, что boost делает всё для того, чтобы кешем пользовался фронтенд, будь то apache или nginx, без обращения к php.
Соревнование не корректно в контексте 1 часа кеша. Новостные сайты с редко позволяют себе делать кеш даже на 5 минут, чаще — 1 минута. На выборке в 50 тысяч нод с реальным разбросом пользователей по нодам ваш 10 мб кеш будет задействован на 40-50%, вряд ли больше. Так что на реальной новостной аудитории вашему методу предпочтительнее связка memcached + cacherouter + authcache. Куском boost и кешем nginx вы ее к сожалению не замените.
2. Как причастный к новостным сайтам авторитетно заявляю, что пользователи ненавидят на них регистрироваться и логиниться. Да и серверу легче от кеша, чем от перегенерации под зарегистрированных. Кстати в drupal.org/project/authcache очень оригинальный подход к ролевому кешу — никнейм и адрес личной страницы грузятся через ajax, а страница для всех пользователей одной роли кеширована. Советую присмотреться для улучшения вашего функционала.
Я конечно не он, но оптимизировал как раз новостные сайты на drupal. Могу предложить ознакомиться с drupal.org/project/authcache. В связке с memcached по опыту дает неплохие результаты для сайтов с высокой степенью обновляемости.
3. Это давно сделано drupal.org/node/244072
4. И в кеш попадут страницы /node/10?keys=asdf наряду с /node/10. Как вы можете проконтролировать все варианты url для одной страницы, закешированной самим nginx? boost это делает на php.
Не вопрос, но посмотрите в сторону boost там это уже реализовано. другим методом в самом nginx, но переписать настройку nginx и десток строк boost проще, чем пытаться предсказать ключ $host$uri?$args
если было бы возможно так легко отделаться, то я бы не стал с вами спорить, а давно бы так и закодил. Однако кеш страницы во многих случаях нужно сбрасывать не только при изменении нода и комментариев, но и при изменении блоков, которые выведены на эту страницу. В случае новостных, например, у меня на странице новости расположены блоки со списками последних новостей тех рубрик, в которые входит эта новость. И блок с последними комментариями ко всем страницам. Это важнейший элемент юзабилити конкретного сайта. Вы уже представили себе механизм, позволяющий обновлять эти блоки дешевле, чем перегенерация страницы? (про недостаток ajax-решения напишу ниже)
по переписке в комментариях
вы не рассмотрели описанную мною вероятность появления нагрузки за счет механизма «дропанья кеша», а зря. Но надеюсь вы найдете время проверить это в максимально реалистичных условиях.
Какую по-вашему роль он выполняет? Только кеширует страницы? Если так, то советую рассмотреть и остальной его функционал, а именно — замену всего механизма кеширования drupal (который основан на RDBMS) на более дешевые — кеш в памяти, модулях php и на диске. Вы удивитесь насколько это ускоряет рендеринг страниц.
Я говорил о вашей SQL базе, из которой берутся ноды, блоки и формы для рендеринга страниц пока не поставишь cacherouter.
Идея очевидная, но конкурентного преимущества не дает. Нужно обновлять страницы еще по множеству поводов. Но самое главное — надо избежать торможения даже на первичной генерации страниц для кеша. И потому, что каждый запрос важен и потому, что кеш будет очищаться часто. Так что облегчать работу для бэкэнда надо обязательно, чему и служат cacherouter с authcache
Уверен, вы знакомы с поисковой оптимизацией. Отдавать блоки со списками статей, релевантных текущему ноду при помощи ajax это очень большая ошибка. Можно обновлять на странице через ajax что угодно, но отдавать html анонимному посетителю, а значит и поисковику надо вместе со всеми релевантными ссылками. Думаю вам дальше понятен ход моих мыслей.
Не преувеличивайте. Никто ТОЛЬКО ради куки такой модуль ставить не будет. Опять же в чем проблема, если куку ставит этот модуль, а не ваш? Для вашего решения с nginx это одинаково, но cacherouter ускоряет drupal в любом случае по сравнению с вашим модулем.
вы правы, я давно не запускал друпал без cacherouter.
2. Вы предлагаете сэкономить производительность отказавшись от динамичности. Для сферического коня в вакууме разница в скорости работы кешей nginx и cacherouter всегда на стороне nginx, но для реального новостного сайта условия не такие:
— пользователи переписываются в комментариях, ведут там такие же интерактивные дискуссии, как и мы тут с вами. И анонимные намного активнее! Предлагаете отказать им в этих возможностях ради красоты вашего решения?
— все активные ноды не помещаются ни в памяти ни в кеше за раз, если это настоящий серьезный проект.
— обновления некоторых блоков требует полного сброса кеша в конкретную минуту времени. В какой-то момент ваш механизм актуализации кеша будет больше заниматься удалением файлов, чем их выдачей пользователям. (я с этим уже экспериментировал)
— чем выручает cacherouter, так это независимым кешированием блоков, которое дает обойтись малой кровью при сборке страниц, даже для последующего кеширования.
— пытаясь обойтись без cacherouter одним кешем nginx в таких условиях вы рискуете проиграть в производительности за счет многочисленных обращений к базе за кешем(!).
Не сочтите за грубость, но я отлично понимаю что и почему вы имеете в виду, поскольку сам так расставлял приоритеты, пока не встрял в реальный новостной проект. Тут нельзя сказать, «пусть логинятся если хотят актуальности», как говорите вы. Тут невозможно закладываться на то, что 100 одновременных авторизованных пользователей могут потерпеть полного рендеринга 100 разных страниц одновременно и обновить страницу если будет таймаут. Задача в том, чтобы никакая страница не рендерилась больше 400 мсек, иначе начнется лавина таймаутов. Критически важно для конкуренции, чтобы никакая информация не задержалась более, чем на несколько секунд. Тут не до теоретизирования «что быстрее выстреливает кешированную страницу php или nginx». Вот в чем я вижу некорректность вашего спора.
Да и делается он бекендом после bootstrap. Где уж тут выигрыш в производительности перед boost?
1. Если вы хотите встроить в Drupal механизм очистки кеша, то учитывать вам нужно все разные url одной страницы, не так ли?
2. Если вы не хотите давать врагам возможность досить ваш кеш и механизм кеширования, лучше бы иметь инструмент очистки кеша от паразитных url
4. И в кеш попадут страницы /node/10?keys=asdf наряду с /node/10. Как вы можете проконтролировать все варианты url для одной страницы, закешированной самим nginx? boost это делает на php.