1

我一直在赶上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 进程的命中率降低吗？没有那么多来回来确定内容是否过时，这意味着比反向代理缓存更好的性能。为什么你可以结合使用这两种技术？

4

4 回答 4

2

你说的对。

考虑它的唯一原因是您的 apache 设置的标头是否过期。在此配置中，代理可以减轻 apache 的一些负载。

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

您将获得的好处将是您的无页面可缓存内容。

我更喜欢使用代理缓存而不是页面缓存（ala heroku），但这只是我，而且是题外话。

于 2010-01-29T16:28:03.293 回答
1

当使用 prefork MPM 时，一个好的代理缓存实现（例如，Squid、Traffic Server）比 Apache 具有更大的可扩展性。如果您使用的是工作 MPM，Apache 是可以的，但代理在高负载（每秒数万个请求）下仍然具有更高的可扩展性。

于 2010-04-30T23:19:11.720 回答
1

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

于 2010-06-17T15:57:31.907 回答
0

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

考虑具有 2 个应用服务器的设置：

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

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

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

于 2010-08-15T22:43:12.583 回答