на пустом месте cacherouter ускоряет ровно в 1 раз. если его поставить для установки куки DRUPAL_UID.
напомню, ветка именно об этом. вы утверждали, что у залогиненных есть кука DRUAPL_UID, а ее нет.
По поводу кемпа — я очень надеюсь что при нашей поддержке он пройдет в Москве в феврале-марте.
По поводу замеров — можем сделать все по взрослому. Взять сайт с несколькими десятками тысяч нод, возьмем HP LoadRunner и погоняем его. А потом посмотрим аналитику.
1. Вопрос решается практически копипастом куска модуля boost в свой. Как я уже говорил, мы это обязательно сделаем.
2. Важность сомнительна. Если пользователю так интересен сайт — он, наверно, авторизуется и будет получать все в обход кэша. Впрочем, это решаемо в пункте 1, причем весьма тривиально.
3+4. Даже предположение вполне конструктивно. Как минимум есть разница в сетевых издержках между фронтэндом и бекэндом, вы же не будете это отрицать?
Так или иначе предлагаю соревнование :) Я на следующем друпалкемпе приведу в презентации сравнение этих методов на основе тестов. Ставка — литр виски :) А до той поры дискуссию отложим.
а в чем хвала? понятно, что лучше вывешивать всегда актуальную информацию, однако 1 час — не такая уж большая потеря в актуальности для многих проектов.
1. Вы немного не поняли. Если фронтэнд находится на отдельном сервере от бекэнда(как у нас допустим) — nginx придется обращаться по сети к другому серверу за кэшем. Зачем?
2. Кэш отдается на фронте, а не на бэке. Это быстрее в любом случае.
3. Drupal + nginx. Никак факторов в пользу второй связки нет.
4. Разница в любом случае есть. Если для производительности ваших проектов она не критична — это вопрос другой.
по вышеописанному методу — детальное сравнение буду готовить только к следующему DrupalCamp. Могу лишь сказать, что для анонимных пользователей нагрузка фактически ограничивается ресурсами сервера и перестает зависеть от Друпала. Сайт практически аналогичен набору html страниц.
да, данный конфиг nginx используется если бекэнд — вебсервер.
как верно замечено по ссылке selfchief, нужно заменить в конфиге proxy_ на fastcgi_, вставить несколько переменных — и все будет работать.
ответ достаточно сложен. попробую объяснить :)
Начнем с того, что как вы верно заметили — мое решение не коробочное, и оно должно применяться, когда посещаемость действительно высока — и любые способы повышения производительности важны.
1. nginx-фронтэнд может находиться на отдельном сервере — кэш будет лежать там же — и отдаваться значительно быстрее
2. nginx в любом случае быстрее отдает статику
3. Drupal может стоять на nginx — в этом случае надо переделывать реврайты boost — оно надо?
4. В случае с boost задача кэширования отдается на бекэнд — этого можно избежать
Не узнает, страница для анонима обновится только через час.
Однако есть простое решение — мы его допишем и выложим. Если вкратце, то необходимо повесить хук на добавление комментария или изменение ноды, который удаляет соответствующий файл из кэша. Файл найти просто — md5 от ключа из конфига.
Такой метод Игорь Сысоев одобряет.
Ловко вы нас раскрыли :) А проект был разработан в течении 3-х месяцев.
Все хочу опубликовать статью о разработке Госбука и интранета для ФАС на друпале, да карма подкачала.
напомню, ветка именно об этом. вы утверждали, что у залогиненных есть кука DRUAPL_UID, а ее нет.
а если его ставить только для выставления куки — то вреднее
1) authcache можно применять и при кэшировании nginx и при cacherouter + memcache.
разница в производительности без тестов не очевидно.
2) сравнивать на тестах мы будем технологии кэширования, которые не предусматривают задержек, в том числе и кэширование с использованием nginx
По поводу замеров — можем сделать все по взрослому. Взять сайт с несколькими десятками тысяч нод, возьмем HP LoadRunner и погоняем его. А потом посмотрим аналитику.
2. Важность сомнительна. Если пользователю так интересен сайт — он, наверно, авторизуется и будет получать все в обход кэша. Впрочем, это решаемо в пункте 1, причем весьма тривиально.
3+4. Даже предположение вполне конструктивно. Как минимум есть разница в сетевых издержках между фронтэндом и бекэндом, вы же не будете это отрицать?
Так или иначе предлагаю соревнование :) Я на следующем друпалкемпе приведу в презентации сравнение этих методов на основе тестов. Ставка — литр виски :) А до той поры дискуссию отложим.
и да, может быть действительно расскажете? :)
2. Кэш отдается на фронте, а не на бэке. Это быстрее в любом случае.
3. Drupal + nginx. Никак факторов в пользу второй связки нет.
4. Разница в любом случае есть. Если для производительности ваших проектов она не критична — это вопрос другой.
www.metaltoad.com/blog/quick-drupal-cacherouter-and-boost-benchmarks
по вышеописанному методу — детальное сравнение буду готовить только к следующему DrupalCamp. Могу лишь сказать, что для анонимных пользователей нагрузка фактически ограничивается ресурсами сервера и перестает зависеть от Друпала. Сайт практически аналогичен набору html страниц.
как верно замечено по ссылке selfchief, нужно заменить в конфиге proxy_ на fastcgi_, вставить несколько переменных — и все будет работать.
он не входит в поставку Drupal 6
Начнем с того, что как вы верно заметили — мое решение не коробочное, и оно должно применяться, когда посещаемость действительно высока — и любые способы повышения производительности важны.
1. nginx-фронтэнд может находиться на отдельном сервере — кэш будет лежать там же — и отдаваться значительно быстрее
2. nginx в любом случае быстрее отдает статику
3. Drupal может стоять на nginx — в этом случае надо переделывать реврайты boost — оно надо?
4. В случае с boost задача кэширования отдается на бекэнд — этого можно избежать
Однако есть простое решение — мы его допишем и выложим. Если вкратце, то необходимо повесить хук на добавление комментария или изменение ноды, который удаляет соответствующий файл из кэша. Файл найти просто — md5 от ключа из конфига.
Такой метод Игорь Сысоев одобряет.
Кластер из 4-х серверов с sas и 16 гигами оперативы, nginx + кэширование для анонимных пользователей, затюненый Drupal.
Все хочу опубликовать статью о разработке Госбука и интранета для ФАС на друпале, да карма подкачала.