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

Я не отставал от скринкастов 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? Нет необходимости в том, чтобы определить, устарел ли контент, что означает лучшую производительность, чем кэширование обратного прокси. Почему вы можете использовать оба метода вместе?


ruby-on-rails http apache reverse-proxy page-caching
person John Topley    schedule 29.01.2010    source источник

Ответы (4)


arrow_upward
2
arrow_downward

Ты прав.

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

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

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

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

person cwninja    schedule 29.01.2010
comment
Спасибо. Мне было бы интересно услышать, почему вы его предпочитаете, если вы не возражаете немного расширить свой ответ. - person John Topley; 29.01.2010
comment
Еще одна вещь, о которой стоит упомянуть, заключается в том, что кеширование страниц осуществляется для каждого приложения, и если вы используете обратный прокси-сервер, вы можете это консолидировать. - person jonnii; 29.01.2010
comment
Если у меня есть это право, после того, как страница будет сгенерирована, прокси-сервер будет работать со статическим файлом, что не является значительным ускорением. - person Toby Hede; 30.01.2010

arrow_upward
1
arrow_downward

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

person Mark Nottingham    schedule 30.04.2010

arrow_upward
1
arrow_downward

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

person dolzenko    schedule 17.06.2010

arrow_upward
0
arrow_downward

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

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

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

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

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

person Railsmechanic    schedule 15.08.2010