我一直在追赶Scaling Rails截屏视频。在涵盖高级HTTP缓存的episode 11中（使用反向代理缓存，如Varnish和Squid等），他们建议只在考虑使用反向代理缓存时，如果已经用尽了页面，操作和片段缓存的可能性您的Rails应用程序（以及memcached等，但这与此问题无关）。
我不太明白的是，使用HTTP反向代理缓存可以为已经使用页面缓存的应用程序提供性能提升。为了简化问题，让我们假设我在这里谈论一个主机。
这是我对两种技术如何运作的理解（也许我错了）：
通过页面缓存，最初会触发Rails进程，然后生成一个静态HTML文件，该文件由Web服务器直接为后续请求提供服务，只要该请求的缓存有效即可。如果缓存已过期，则再次点击Rails并重新生成静态文件，并为下一个请求准备好更新的内容
使用HTTP反向代理缓存，当代理需要确定内容是否陈旧时，会触发Rails进程。这是使用各种HTTP标头完成的，例如ETag，Last-Modified等。如果内容是新鲜的，则Rails使用HTTP 304 Not Modified响应代理，并且代理将其缓存的内容提供给浏览器，甚至更好，用自己的HTTP 304进行响应。如果内容是陈旧的，那么Rails将更新的内容提供给代理，代理将其缓存，然后将其提供给浏览器
如果我的理解是正确的，那么页面缓存不会导致对Rails进程的点击次数减少吗？没有来回确定内容是否陈旧，这意味着比反向代理缓存更好的性能。为什么你可以结合使用这两种技术？
答案 0 :(得分：2)
你是对的。
考虑它的唯一原因是你的apache设置是否过期。在此配置中，代理可以从apache中获取一些负载。
话虽如此，apache静态与代理缓存在rails世界中几乎是无关紧要的。它们都是天文学上快速的。
您将获得的好处是您的无页面可缓存内容。
我更喜欢在页面缓存（ala heroku）上使用代理缓存，但这只是我和一个题外话。
答案 1 :(得分：1)
使用prefork MPM时，良好的代理缓存实现（例如，Squid，Traffic Server）比Apache的可扩展性大得多。如果您正在使用worker MPM，那么Apache就可以了，但是在高负载（数万个请求/秒）下，代理仍然可以更加可扩展。
答案 2 :(得分：1)
Varnish具有一项功能。这可以防止一些令人讨厌的狗堆案例，这在传统的页面缓存场景中几乎不可能解决。
答案 3 :(得分：0)
在只有一个应用服务器的设置中使用反向代理似乎有点矫枉过正IMO。 在具有多个应用服务器的配置中，反向代理（例如清漆等）是页面缓存的最有效方式。
考虑使用2个应用服务器进行设置：
用户'Bob'（重定向到节点'A'）发布新消息，页面过期并在节点'A'上重新创建。
用户'Cindy'（重定向到节点'B'）请求显示来自'Bob'的新消息的页面，但是她看不到新消息，因为节点'B'上的页面没有过期并重新创建。
这个并发问题可以用反向代理解决。