铁轨'页面缓存与 HTTP 反向代理缓存
我一直在观看 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 进程的点击次数吗？无需来回确定内容是否过时，这意味着比反向代理缓存有更好的性能。为什么可以结合使用这两种技术？
I've been catching up with the Scaling Rails screencasts. In episode 11 which covers advanced HTTP caching (using reverse proxy caches such as Varnish and Squid etc.), they recommend only considering using a reverse proxy cache once you've already exhausted the possibilities of page, action and fragment caching within your Rails application (as well as memcached etc. but that's not relevant to this question).
What I can't quite understand is how using an HTTP reverse proxy cache can provide a performance boost for an application that already uses page caching. To simplify matters, let's assume that I'm talking about a single host here.
This is my understanding of how both techniques work (maybe I'm wrong):
With page caching the Rails process is hit initially and then generates a static HTML file that is served directly by the Web server for subsequent requests, for as long as the cache for that request is valid. If the cache has expired then Rails is hit again and the static file is regenerated with the updated content ready for the next request
With an HTTP reverse proxy cache the Rails process is hit when the proxy needs to determine whether the content is stale or not. This is done using various HTTP headers such as
ETag,Last-Modifiedetc. If the content is fresh then Rails responds to the proxy with an HTTP 304 Not Modified and the proxy serves its cached content to the browser, or even better, responds with its own HTTP 304. If the content is stale then Rails serves the updated content to the proxy which caches it and then serves it to the browser
If my understanding is correct, then doesn't page caching result in less hits to the Rails process? There isn't all that back and forth to determine if the content is stale, meaning better performance than reverse proxy caching. Why might you use both techniques in conjunction?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
你是对的。
考虑它的唯一原因是您的 apache 设置了过期标头。在此配置中，代理可以减轻 apache 的部分负载。
话虽如此，apache 静态缓存与代理缓存在 Rails 世界中几乎是无关紧要的。它们的速度都快得惊人。
您将获得的好处是您的无页面可缓存内容。
我更喜欢使用代理缓存而不是页面缓存（ala heroku），但这只是我的观点，而且是题外话。
You are right.
The only reason to consider it is if your apache sets expires headers. In this configuration, the proxy can take some of the load off apache.
Having said this, apache static vs proxy cache is pretty much an irrelevancy in the rails world. They are both astronomically fast.
The benefits you would get would be for your none page cacheable stuff.
I prefer using proxy caching over page caching (ala heroku), but thats just me, and a digression.
当使用 prefork MPM 时，一个好的代理缓存实现（例如，Squid、Traffic Server）比 Apache 具有更高的可扩展性。如果您使用的是工作 MPM，Apache 就可以，但是代理在高负载（每秒数万个请求）下仍然具有更高的可扩展性。
A good proxy cache implementation (e.g., Squid, Traffic Server) is massively more scalable than Apache when using the prefork MPM. If you're using the worker MPM, Apache is OK, but a proxy will still be much more scalable at high loads (tens of thousands of requests / second).
例如，Varnish 有一个功能，当对同一 URL（不在缓存中）的同时请求排队时，只有单个/第一个请求实际上到达后端。这可以防止一些令人讨厌的狗堆情况，这些情况在传统的页面缓存场景中几乎不可能解决。
Varnish for example has a feature when the simultaneous requests to the same URL (which is not in cache) are queued and only single/first request actually hits the back-end. That could prevent some nasty dog-pile cases which are nearly impossible to workaround in traditional page caching scenario.
在只有一个应用程序服务器的设置中使用反向代理在我看来似乎有点矫枉过正。
在具有多个应用程序服务器的配置中，反向代理（例如varnish等）是页面缓存的最有效方法。
考虑使用 2 个应用服务器的设置：
用户“Bob”（重定向到节点“A”）发布一条新消息，页面过期并在节点“A”上重新创建。
用户“Cindy”（重定向到节点“B”）请求应该显示来自“Bob”的新消息的页面，但她看不到新消息，因为节点“B”上的页面没有显示过期并重新创建。
这个并发问题可以通过反向代理来解决。
Using a reverse proxy in a setup with only one app server seems a bit overkill IMO.
In a configuration with more than one app server, a reverse proxy (e.g. varnish, etc.) is the most effective way for page caching.
Think of a setup with 2 app servers:
User 'Bob'(redirected to node 'A') posts a new message, the page gets expired and recreated on node 'A'.
User 'Cindy' (redirected to node 'B') requests the page where the new message from 'Bob' should appear, but she can't see the new message, because the page on node 'B' wasn't expired and recreated.
This concurrency problem could be solved with a reverse proxy.