Является ли Varnishd правильным решением для кэширования, которое можно использовать с Rails?

Question

Я хочу кэшировать полные страницы нашего веб-приложения (тысячи страниц), которые отображаются в стеке Rails, но меняются не очень часто.Каждый рендер довольно дорогой с точки зрения ресурсов.

Насколько я понимаю, как работает Varnishd, так это то, что при первоначальном обращении к URL-адресу Varnishd проверит свое хранилище кеша, произойдет промах и запросбудет передан в Rails, и полученная страница, которая будет сгенерирована, будет затем добавлена ​​в кеш Varnishd.

При любых последующих вызовах, сделанных на этот URL и затем обслуживаемых из кеша Varnishd, стек Rails не задействуется.

Это правильно или я не в порядке?

Как мое приложение может сообщать Varnishd об обновлении конкретной страницы и отображать любые изменения, внесенные в ее кэш-хранилище?

Является ли Varnishd хорошим выбором для этой цели?

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

Answer 1

Для динамического аннулирования кэша вы можете отправить purge.url {some regexp} с вашего сервера приложений по каналу управления.Например, purge.url "^/some/page/$".Однако из Rails, вероятно, проще всего использовать метод HTTP PURGE.Таким образом, вместо выполнения HTTP GET вы должны использовать PURGE для того же URI:

PURGE /some/page/ HTTP/1.0
Host: example.com

Этот запрос должен поступать с localhost, если вы не переопределите его в конфигурации.

Некоторые ссылки:

• http://www.varnish -cache.org / trac / wiki / VCLExamplePurging
• http://www.varnish -cache.org/trac/wiki/Purging
• http://kristianlyng.wordpress.com/2010/02/02/varnish-purges/

Answer 2

Я рекомендую прочитать это руководство по кешированию HTTP Марка Ноттингема: http://www.mnot.net/cache_docs/

Чтобы использовать обратный прокси-сервер с кешированием, вам нужно будет указать время истечения в ваших ответах http.Как правило, невозможно «сообщить» серверу кэширования, когда доступен новый контент, потому что протокол предназначен для федерации через Интернет, и вам не нужно сообщать серверам по всему миру, когда у вас есть новые картинки kittin: -)

Кэширование страниц Rails - это совсем не одно и то же.Это просто переносит работу на веб-сервер для статической обработки файлов, но не включает протокол http в решение.

Предостережение: я должен отметить, что я не пробовал Varnish лично.Этот ответ основан на (я думаю правильном) предположении, что Varnish является обратным прокси-сервером для кэширования http.

Answer 3

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

Вы можете настроить Varnish для ответа на запрос HTTP PURGE, который позволит Rails сообщать Varnish об изменении страницы. Вот плагин и статья в том же духе.

Answer 4

Как уже упоминалось в ответе noodl, при использовании обратного прокси-сервера, как правило, срок действия страницы истекает из-под вашего контроля. Альтернативный подход заключается в том, что вам нужно будет управлять истечением срока действия: использовать rails кэширование страниц (см. Раздел 1.1), это заставляет rails отображать ответ на диск (в публичный каталог) при первом вызове действия. и вы можете использовать ваш интерфейсный веб-сервер для непосредственного обслуживания этих HTML-файлов. Для этого я использую nginx, и у меня есть директива для обслуживания любых существующих статических файлов (как правило, изображений, но работает и для HTML-страниц с правильным перезаписыванием для учета расширения .html). С помощью кеша, управляемого rails, вы можете истечь сами, как в примере на странице руководств, где истекает индекс при создании нового элемента.

Насколько я понимаю, обратные прокси-серверы HTTP предназначены и помогают повысить производительность, когда у вас очень высокая пропускная способность, поскольку это позволяет кэшам распространяться в части сети вне вашего контроля, однако, если это время рендеринга, как вы предлагаете, тогда Кэширование страницы rails может быть хорошим вариантом для вас.