Boost crawler не обязательно включать. Он нужен если вы хотите в фоне генерить кеш. Если его выключить, то кеш будет генериться на лету, то есть если есть закешированная версия страницы, то будет отдаваться она, если нет, то страница будет создана, закеширована и отдана юзеру.
Да, решает, если мы хотим отправлять сообщение в рамках существующей подписки
Не понял о чем речь. Рассылать письма можно всем зарегистрированным пользователям (с фильтром по ролям, например) вне зависимости от того, подписывался пользователь на рассылку явно или нет.
Так или иначе предлагаю соревнование :) Я на следующем друпалкемпе приведу в презентации сравнение этих методов на основе тестов. Ставка — литр виски :) А до той поры дискуссию отложим.
Ок, договорились. Речь о кемпе в Киеве? В Москве с кемпами как-то тухло. Правда непонятно как будут проводиться замеры…
2. Важность сомнительна.
Для проекта над которым работаю я наличие обновляемого по запросу кеша имеет максимальную важность.
Если пользователю так интересен сайт — он, наверно, авторизуется и будет получать все в обход кэша.
Пользователю интересен не сайт, а новость. Если он её не увидел, то он уйдет на другой сайт. Иногда, совсем редко, возникают экстраординарные события, которые вызывают огромный интерес у посетителей и информация о которых обновляется чуть ли не каждые 5 минут. В такие моменты посещаемость новостных сайтов увеличивается в разы. Для таких ситуаций кеш на час — это беда.
Кроме того важно забывать про поисковики, которые тоже индексируют сайты под анонимом. В вашем случае вполне велика вероятность того, что вы опубликуете новость раньше конкурентов, но из-за кеша в поисковик она попадет позже и, как следствие, поисковик (или новостной агрегатор) в выдаче поставит ссылки не на вас.
1. Вы немного не поняли. Если фронтэнд находится на отдельном сервере от бекэнда(как у нас допустим) — nginx придется обращаться по сети к другому серверу за кэшем.
У нас тоже.
Зачем?
Затем, что можно получить более гибкий кеш, обновляемый вместе с обновлением контента, а не по таймеру.
2. Кэш отдается на фронте, а не на бэке. Это быстрее в любом случае.
В очередной раз повторю. В таком случае если у вас обновился материал, добавились комментарии или, например, обновился какой-то блок (это может быть очень важно для новостных сайтов, когда появляется по 10 новых новостей в час и на каждой из страниц выводится блок с последними новостями), то анонимы всех этих обновлений не увидят до очистки кеша.
3. Drupal + nginx. Никак факторов в пользу второй связки нет.
4. Разница в любом случае есть. Если для производительности ваших проектов она не критична — это вопрос другой.
Это ваше предположение или вы проводили тесты? Если предположение, то оно абсолютно не конструктивно. Если были тесты, то было бы интересно увидеть их условия и результаты.
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 держит нагрузку более миллиона хитов в сутки (для сайта на Друпале это неплохо) и, судя по мониторингу, выдержит и сильно бОльшую нагрузку.
С бустом также: в .htaccess прописывается блок правил, который по куке проверяет является пользователь анонимом или нет, если является, то запрошенный УРЛ ищется в файловом кеше, и только если в кеше нет файла, то тогда дергается php + Drupal. Если файл с закешированной страницей в кеше есть, то Апач отдает его не вызывая никаких php-скриптов.
А чем плох модуль boost? Он делает примерно тоже самое: отдает кеш анонимам минуя Друпал, только кеш хранится в файловой системе, а не в оперативной памяти (я ведь правильно понимаю, что кеш энжиникса находится в RAM?). Судя по логам, у нас страницы Апачем отдаются энжиниксу за 5-10 милисекунд. Только вот у буста нет описанной выше проблемы: его можно настроить так, что при обновлении страницы сбрасывался её кеш.
Все-таки сомнительна полезность этого сервиса. По крайней мере в том виде, в котором он есть сейчас. Абсолютно все пункты, которые вы перечислили в «основных возможностях», «основных моментах» и «преимуществах» доступны через интерфейс гуглокарт, кроме того через стандартный интерфейс карт Гугла на карте можно размещатьи линии, и полигоны, и метки с балунами. То есть сделать можно карту типа такой. Ну и встроить ее на свою страницу можно без API KEY, ключ нужен только для того, чтобы на своем сайте средствами java-script взаимодействовать с картой.
Непонятно почему пост минусуют. Первый Ведьмак был ооочень интересной и увлекательной игрушкой, поглощенный этой игрой я года полтора-два назад выпал на две недели из реальной жизни. Давно на меня игры не производили такого впечатления. С нетерпением жду второй части.
Он не не устраивает, просто изначально я вообще не знал о том какие есть инструменты для решения этой задачи, по этому по запросу в гугле я нашел эту страницу и испытал перечисленные на ней утилиты на предмет работоспособности и соответствия моим требования. Кстати, насколько я понял ни fsbackup, ни rsnapshot не копируют данные на S3, а это для меня было одним из ключевых требований.
Спорное утверждение, на мой взгляд зарегистрировать аккаунт на Амазоне проще чем ставить где-то (в идеале в датацентре отличном от того, в котором стоит «бэкапируемый» сервер) еще одну железяку, чтобы переносить на нее данные по FTP.
Не понял о чем речь. Рассылать письма можно всем зарегистрированным пользователям (с фильтром по ролям, например) вне зависимости от того, подписывался пользователь на рассылку явно или нет.
Ок, договорились. Речь о кемпе в Киеве? В Москве с кемпами как-то тухло. Правда непонятно как будут проводиться замеры…
2. Важность сомнительна.
Для проекта над которым работаю я наличие обновляемого по запросу кеша имеет максимальную важность.
Если пользователю так интересен сайт — он, наверно, авторизуется и будет получать все в обход кэша.
Пользователю интересен не сайт, а новость. Если он её не увидел, то он уйдет на другой сайт. Иногда, совсем редко, возникают экстраординарные события, которые вызывают огромный интерес у посетителей и информация о которых обновляется чуть ли не каждые 5 минут. В такие моменты посещаемость новостных сайтов увеличивается в разы. Для таких ситуаций кеш на час — это беда.
Кроме того важно забывать про поисковики, которые тоже индексируют сайты под анонимом. В вашем случае вполне велика вероятность того, что вы опубликуете новость раньше конкурентов, но из-за кеша в поисковик она попадет позже и, как следствие, поисковик (или новостной агрегатор) в выдаче поставит ссылки не на вас.
У нас тоже.
Зачем?
Затем, что можно получить более гибкий кеш, обновляемый вместе с обновлением контента, а не по таймеру.
2. Кэш отдается на фронте, а не на бэке. Это быстрее в любом случае.
В очередной раз повторю. В таком случае если у вас обновился материал, добавились комментарии или, например, обновился какой-то блок (это может быть очень важно для новостных сайтов, когда появляется по 10 новых новостей в час и на каждой из страниц выводится блок с последними новостями), то анонимы всех этих обновлений не увидят до очистки кеша.
3. Drupal + nginx. Никак факторов в пользу второй связки нет.
4. Разница в любом случае есть. Если для производительности ваших проектов она не критична — это вопрос другой.
Это ваше предположение или вы проводили тесты? Если предположение, то оно абсолютно не конструктивно. Если были тесты, то было бы интересно увидеть их условия и результаты.
Я писал выше, что Апач отдает энжиниксу страницу закешированную бустом за 5-10 милисекунд. Не такая уж и критичная задержка, но при этом буст значительно более гибок в настройке.
2. nginx в любом случае быстрее отдает статику
Как это связано с кешем? У нас в проекте тоже nginx отдает статику (css, js, картинки).
3. Drupal может стоять на nginx — в этом случае надо переделывать реврайты boost — оно надо?
Либо ставить за nginx'ом апач и есть большой вопрос что будет работать шустрее nginx + Drupal без буста или nginx + Apache + Drupal + boost, уж очень много на это влияет факторов.
4. В случае с boost задача кэширования отдается на бекэнд — этого можно избежать
Зачем этого избегать? В любом случае один раз Друпалу придется сгенерировать страницу для анонима, а потом уже почти без разницы кто эту страницу закеширует и отдаст другому анониму.
мое решение не коробочное, и оно должно применяться, когда посещаемость действительно высока
У нас связка nginx + Apache + Drupal + boost держит нагрузку более миллиона хитов в сутки (для сайта на Друпале это неплохо) и, судя по мониторингу, выдержит и сильно бОльшую нагрузку.
Slice archives to 2 GB if using dar archives format.
Это же ограничение на один слайс, распилить архив можно на сколько угодно кусков.
Спорное утверждение, на мой взгляд зарегистрировать аккаунт на Амазоне проще чем ставить где-то (в идеале в датацентре отличном от того, в котором стоит «бэкапируемый» сервер) еще одну железяку, чтобы переносить на нее данные по FTP.
а вот ограничение на 2 гигабайта — это неудобно
А где такое ограничение?