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

Question

我一直在赶上Scaling Rails截屏视频。在包含高级HTTP缓存（使用反向代理缓存（如Varnish和Squid等））的episode 11中，他们建议只有在已经耗尽了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（不在缓存中）的同时请求排队并且只有单个/第一个请求实际上碰到后端时。这可以防止传统页面缓存场景中几乎不可能解决的一些令人讨厌的狗桩事件。

Answer 4

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

思考与2的应用服务器的设置的：

• “用户鲍勃（重定向到节点“A”）发布一个新的消息，该页面被过期并重新创建节点“A”。

• 用户'Cindy'（重定向到节点'B'）请求应该出现'Bob'的新消息的页面，但她看不到新消息，因为节点'B'上的页面没有过期并重新创建。

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