Каковы были бы преимущества использования etags/stale?/Fresh_when? вместо кэширования страниц (в кеше файлов)?Рельсы - etags против кэширования страниц (кеш файлов)
Apache автоматически обрабатывает etags для статических файлов, но даже если это не так, кэширование страниц все равно будет лучше, так как приложение Rails даже не вызвано.
Итак, в каких случаях я бы использовал методы, предоставляемые Rails (устаревшие?/Fresh_when?)?
Они действительно бесплатны. Etags/fresh_when и т. Д. Помогут вам хорошо играть с нисходящими кэшами (например, ваши собственные экземпляры Varnish/Squid или Rack :: Cache или кеш браузера или прокси-серверы интернет-провайдера ...)
Кэширование страницы экономит ваше время, Файл Apache/ваш веб-сервер обслуживается, поэтому никаких запросов DB не выполняется. Но вам нужно иметь дело с истечением кеша, чтобы сохранить кеш свежим.
Использование ETags/условный GET, вы не сэкономите много времени обработки, так как вам все еще нужно, чтобы получить все записи, используемые на странице:
def show
@article = Article.find(params[:id])
@feature = Feature.current
fresh_when :etag => [@article, @feature]
end
в том случае, если пользователь имеет текущую страницу , это экономит ваше время рендеринга и пропускную способность, необходимую для отправки страницы.
Две поправки: 1) Mainline Varnish не поддерживает ETags, но есть экспериментальная ветвь «экспериментальные-ims» в исходном репозитории, в котором она реализована. 2) Вы можете сэкономить значительное время обработки с помощью ETags, сохранив значение ETag для данной страницы отдельно от данных, используемых для расчета его значения (таким образом, вам не нужно восстанавливать его, что может быть более дорогостоящим из-за сбоев базы данных) , См. «Поваренная книга веб-служб RESTful», раздел 10.1. – benvolioT
Одна вещь, которая приходит на ум, состоит в том, что fresh_when все равно сохранит вам рендеринг, даже если вы очистили весь кеш страниц. Здесь вы будете использовать оба в тандеме.
Мне также интересны другие ответы.
Другое использование, которое пришло мне в голову, заключалось в том, что вы все равно можете обработать некоторую информацию, прежде чем позволить Rails раздавать заголовок 304 Not Modified. Например, если вы хотите записывать хиты на страницу.
Я думаю, вы имеете в виду страницу кэширования. caches_page будет генерировать статические файлы для веб-сервера для обслуживания напрямую. caches_action будет кэшировать весь контент страницы, но все равно будет проходить через контроллер, чтобы фильтры могли запускаться и т. д. – kch
Правильно, спасибо за головы. – Ivan