我想在我们的Web应用程序（数千页）上缓存由Rails堆栈呈现的完整页面，但不要经常更改。每个渲染在资源方面都非常昂贵。
我对Varnishd如何工作的理解是，当对URL进行初始调用时，Varnishd将检查其缓存存储，将发生未命中，因此请求将传递给Rails，然后将生成的结果页面添加到Varnishd缓存。
对该URL进行的任何后续调用然后从Varnishd缓存提供服务，不涉及Rails堆栈。
这是正确的还是我离开了？
如何更新特定页面并反映其缓存存储中所做的任何更改，我的应用程序如何告诉Varnishd？
Varnishd是否是一个很好的选择？
感谢您的帮助 - 我知道这些是非常基本的问题，但是文档只是不清楚（至少对我来说）。
要进行动态缓存失效，您可以发送 purge.url {some regexp} 从您的应用程序服务器通过管理通道。例如， purge.url "^/some/page/$"。但是，从Rails开始，使用它可能最容易 PURGE HTTP方法。所以不要做HTTP GET你会做的 PURGE 针对相同的URI：
PURGE /some/page/ HTTP/1.0
Host: example.com
这个要求必须来自 localhost 除非您在配置中覆盖它。
一些链接：
我建议阅读Mark Nottingham的HTTP缓存指南： http://www.mnot.net/cache_docs/
为了使用带有缓存的反向代理，您需要在http响应中指定到期时间。当新内容可用时，通常不可能“告诉”缓存服务器，因为该协议旨在通过互联网进行联合，当您有新的kittin图片时，您不希望告诉世界各地的服务器： - ）
Rails页面缓存完全不是一回事。这只是将工作卸载到Web服务器以静态地提供文件，但在决策中不涉及http协议。
警告：我应该指出，我没有亲自尝试过Varnish。这个答案是基于（我认为正确的）假设，即Varnish是一个http缓存反向代理。
要进行动态缓存失效，您可以发送 purge.url {some regexp} 从您的应用程序服务器通过管理通道。例如， purge.url "^/some/page/$"。但是，从Rails开始，使用它可能最容易 PURGE HTTP方法。所以不要做HTTP GET你会做的 PURGE 针对相同的URI：
PURGE /some/page/ HTTP/1.0
Host: example.com
这个要求必须来自 localhost 除非您在配置中覆盖它。
一些链接：
我建议阅读Mark Nottingham的HTTP缓存指南： http://www.mnot.net/cache_docs/
为了使用带有缓存的反向代理，您需要在http响应中指定到期时间。当新内容可用时，通常不可能“告诉”缓存服务器，因为该协议旨在通过互联网进行联合，当您有新的kittin图片时，您不希望告诉世界各地的服务器： - ）
Rails页面缓存完全不是一回事。这只是将工作卸载到Web服务器以静态地提供文件，但在决策中不涉及http协议。
警告：我应该指出，我没有亲自尝试过Varnish。这个答案是基于（我认为正确的）假设，即Varnish是一个http缓存反向代理。
正如noodl的回答中所提到的，如果使用反向代理，通常会使页面过期无法控制。另一种方法是你需要管理到期时才会使用rails 页面缓存 （参见1.1节），这使得rails在第一次调用操作时呈现对磁盘的响应（进入公共目录），并且您可以使用前端Web服务器直接提供这些html文件。我使用nginx，并有一个指令来提供任何存在的静态文件（通常是图像，但也适用于html页面，正确的重写以解释.html扩展名）。通过rails管理缓存，您可以自己过期，就像在指南页面上的示例中那样在创建新项目时使索引到期。
我的理解是反向http代理用于并且当你具有非常高的吞吐量时帮助提高性能，因为它允许缓存传播到控制之外的网络部分，但是如果它按照你的建议渲染时间，那么rails页面缓存对你来说可能是一个不错的选择。
页面缓存是您可能想要的。设置和维护比Varnish更简单。当您开始扩展到多个应用程序服务器时，使用反向代理进行缓存确实有一些优势，因为您可以在单个位置而不是在每个应用程序服务器上使缓存无效。
您可以配置Varnish以响应HTTP PURGE请求，这将使Rails在页面发生更改时告诉Varnish。这是一个 插入 和 文章 沿着这些路线。