Rails的页面缓存与HTTP反向代理缓存

Question

我一直在追赶Scaling Rails的截屏视频。 在第11集中 ，它涵盖了高级HTTP缓存（使用反向代理缓存，如Varnish和Squid等），一旦你已经用尽了Rails应用程序中的页面，动作和片段缓存的可能性，他们建议只考虑使用反向代理缓存（以及memcached等，但这与这个问题无关）。

我不太明白的是，使用HTTP反向代理缓存可以为已经使用页面缓存的应用程序提供性能提升。 为了简化问题，让我们假设我在这里谈论一个主机。

这是我对两种技术如何工作的理解（也许我错了）：

• 通过页面缓存，Rails进程最初被命中，然后生成一个静态HTML文件，该文件由Web服务器直接为后续请求提供服务，只要该请求的缓存有效。 如果缓存已过期，则再次命中Rails并重新生成静态文件，并为更新的内容准备好下一个请求

• 使用HTTP反向代理缓存，当代理需要确定内容是否陈旧时，会触发Rails进程。 这是使用各种HTTP标头完成的，例如ETag ， Last-Modified等。如果内容是新鲜的，那么Rails使用HTTP 304 Not Modified响应代理，代理将其缓存的内容提供给浏览器，甚至更好，响应它自己的HTTP 304.如果内容是陈旧的，那么Rails将更新的内容提供给代理，后者将其缓存，然后将其提供给浏览器

如果我的理解是正确的，那么页面缓存不会导致对Rails进程的点击次数减少吗？ 没有来回确定内容是否陈旧，这意味着比反向代理缓存更好的性能。 为什么你可以结合使用这两种技术？

Answer 1

你是对的。

考虑它的唯一原因是你的apache设置是否过期。 在此配置中，代理可以从apache中获取一些负载。

话虽如此，apache静态与代理缓存在rails世界中几乎是无关紧要的。 它们都是天文学上快速的。

您将获得的好处是您的无页面可缓存的东西。

我更喜欢在页面缓存（ala heroku）上使用代理缓存，但这只是我和一个题外话。

Answer 2

当使用prefork MPM时，良好的代理缓存实现（例如，Squid，Traffic Server）比Apache更具可扩展性。 如果您正在使用worker MPM，那么Apache就可以了，但是在高负载（数万个请求/秒）下，代理仍然可以更加可扩展。

Answer 3

例如，当对同一URL（不在高速缓存中）的同时请求排队并且只有单个/第一个请求实际到达后端时，Varnish具有一个功能。 这可以防止在传统的页面缓存场景中几乎不可能解决的一些讨厌的狗堆案例。

Answer 4

在只有一个应用服务器的设置中使用反向代理似乎有点矫枉过正IMO。 在具有多个app服务器的配置中，反向代理（例如清漆等）是页面缓存的最有效方式。

想想有2个应用服务器的设置：

• 用户'Bob'（重定向到节点'A'）发布新消息，页面过期并在节点'A'上重新创建。

• 用户'Cindy'（重定向到节点'B'）请求显示来自'Bob'的新消息的页面，但是她看不到新消息，因为节点'B'上的页面未过期并重新创建。

这种并发问题可以通过反向代理来解决。