Rails - etags vs. 页面缓存（文件缓存）

Question

使用 etags/stale?/fresh_when? 与页面缓存（文件缓存）相比有哪些优点？

Apache 自动处理静态文件的 etags，但即使它不这样做，页面缓存仍然比较好，因为 Rails 应用程序甚至不会被调用。

那么，在什么情况下我会使用 Rails 提供的方法（stale?/fresh_when?）？

- Ivan

---

我认为你指的是页面缓存。caches_page将生成静态文件，供Web服务器直接提供服务。caches_action将缓存整个页面内容，但仍会通过控制器运行过滤器等操作。 - kch

没错，谢谢提醒。 - Ivan

Answer 1

他们是互补的。ETags / fresh_when等有助于您与下游缓存（如您自己的Varnish / Squid实例或Rack :: Cache或浏览器缓存或ISP代理服务器）进行良好的交互。

页面缓存可使您完全避免访问Rails堆栈，因为Apache / Web服务器提供文件，因此不执行任何DB查找。但是您必须处理缓存过期以保持缓存新鲜。

使用ETags /条件获取，您节省不了太多处理时间，因为仍然需要获取页面上使用的所有记录：

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

如果用户已经有当前页面，那么它可以节省渲染时间和发送页面所需的带宽。

- gerrit

---

两个更正： 1）主线Varnish不支持ETags，但源代码库中有一个实验分支“experimental-ims”，其中已经实现了它。 2）通过将给定页面的ETag值与用于计算其值的数据分开存储（这样您就不必重新生成它，因为数据库获取可能更昂贵），可以节省大量处理时间。请参见“RESTful Web服务食谱”，第10.1节。 - benvolioT

Answer 2

另一个我想到的用途是，在让Rails发出“304未修改”头之前，您仍然可以处理一些信息。比如说您想记录页面的点击次数。

- Ivan

Answer 3

有一件事情值得注意的是，即使您清除了整个页面缓存，fresh_when仍然可以节省一些渲染时间。在这里，您将同时使用两者。

我也很好奇其他答案。

- kch