Rails - etags против кэширования страниц (файловый кеш) - PullRequest
9 голосов
/ 07 мая 2009

Какие преимущества использования etags / stale? / Fresh_when? вместо кеширования страниц (в файловом кеше)?

Apache автоматически обрабатывает etags для статических файлов, но даже если это не так, кэширование страниц все равно будет лучше, поскольку приложение Rails даже не вызывается.

Итак, в каких случаях я бы использовал методы, предоставляемые Rails (stale? / Fresh_when?)?

Ответы [ 3 ]

5 голосов
/ 09 июля 2009

Они действительно бесплатны. Etags / fresh_when и т. Д. Помогают вам хорошо играть с нижестоящими кешами (такими как ваши собственные экземпляры Varnish / Squid или Rack :: Cache или кеш браузера или прокси-серверы ISP…)

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

Используя etags / условное получение, вы не экономите много времени на обработку, так как вам все еще нужно получить все записи, используемые на странице:

def show
  @article = Article.find(params[:id])
  @feature = Feature.current
  fresh_when :etag => [@article, @feature] 
end

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

2 голосов
/ 07 мая 2009

Еще одно использование, которое пришло мне в голову, это то, что вы все еще можете обработать некоторую информацию, прежде чем позволить Rails раздать заголовок «304 Not Modified». Например, если вы хотите записать хиты на страницу.

0 голосов
/ 07 мая 2009

Одна вещь, которая приходит на ум, это то, что fresh_when все равно сохранит вам некоторую визуализацию, даже если вы очистили весь кеш страниц. Здесь вы будете использовать оба в тандеме.

Мне любопытны и другие ответы.

...