Кэширование страниц в Rails против HTTP-кэшей обратного прокси

Question

Я догонял скринкасты Scaling Rails . В эпизоде ​​11 , который охватывает расширенное кэширование HTTP (с использованием кэшей обратного прокси-сервера, таких как Varnish, Squid и т. Д.), Они рекомендуют рассматривать использование кэша обратного прокси-сервера только после того, как вы уже исчерпали возможности страницы, действия и Кэширование фрагментов в вашем Rails-приложении (а также memcached и т. д., но это не относится к этому вопросу).

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

Это мое понимание того, как работают оба метода (возможно, я ошибаюсь):

• При кэшировании страницы изначально запускается процесс Rails, а затем генерируется статический файл HTML, который обслуживается веб-сервером напрямую для последующих запросов, пока кэш этого запроса действителен. Если срок действия кэша истек, тогда Rails снова запускается и статический файл создается заново с обновленным содержимым, готовым к следующему запросу

• При использовании кеша обратного прокси-сервера HTTP процесс Rails запускается, когда прокси-сервер должен определить, устарел ли контент или нет. Это делается с использованием различных заголовков HTTP, таких как ETag, Last-Modified и т. Д. Если содержимое свежее, то Rails отвечает на прокси с HTTP 304 Not Modified и прокси-сервер передает свое кэшированное содержимое в браузер, или даже лучше, отвечает своим собственным HTTP 304. Если содержимое устарело, Rails передает обновленное содержимое прокси, который кэширует его, а затем передает его в браузер

Если мое понимание верно, то не приводит ли кеширование страниц к меньшему количеству попаданий в процесс Rails? Не все, что нужно, чтобы определить, устарел ли контент, что означает лучшую производительность, чем кэширование обратного прокси. Почему вы можете использовать обе техники одновременно?

Answer 1

Вы правы.

Единственная причина, по которой следует это учитывать, - если у ваших наборов apache заголовки expires. В этой конфигурации прокси-сервер может снимать часть нагрузки с Apache.

Сказав это, apache static vs прокси-кеш в значительной степени неуместен в мире рельсов. Они оба астрономически быстрые.

Преимущества, которые вы получили бы, были бы для ваших вещей, не кэшируемых на странице.

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

Answer 2

Например, Varnish имеет функцию, когда одновременные запросы к одному и тому же URL (который не находится в кеше) ставятся в очередь, и только один / первый запрос фактически попадает в серверную часть. Это может предотвратить некоторые неприятные случаи с кучей собак, которые практически невозможно обойти в традиционном сценарии кэширования страниц.

Answer 3

Хорошая реализация прокси-кэша (например, Squid, Traffic Server) значительно более масштабируема, чем Apache, при использовании prefork MPM.Если вы используете рабочий MPM, с Apache все в порядке, но прокси все равно будет гораздо более масштабируемым при высоких нагрузках (десятки тысяч запросов в секунду).

Answer 4

Использование обратного прокси в настройках только с одним сервером приложений кажется немного излишним IMO. В конфигурации с несколькими серверами приложений обратный прокси-сервер (например, лак и т. Д.) Является наиболее эффективным способом кэширования страниц.

Подумайте о настройке с двумя серверами приложений:

• Пользователь «Боб» (перенаправлен на узел «А») публикует новое сообщение, срок действия страницы истекает и воссоздается на узле «А».

• Пользователь «Синди» (перенаправленный на узел «B») запрашивает страницу, где должно появиться новое сообщение от «Боба», но она не может видеть новое сообщение, потому что страница на узле «B» не истек и воссоздан.

Эту проблему с параллелизмом можно решить с помощью обратного прокси.