12

我想在我们的 Web 应用程序（数千个页面）上缓存由 Rails 堆栈呈现的完整页面，但不要经常更改。就资源而言，每次渲染都非常昂贵。

我对 Varnishd 工作原理的理解是，当对 URL 进行初始调用时，Varnishd 将检查其缓存存储，会发生未命中，因此请求将传递给 Rails，然后将生成的结果页面添加到Varnishd 缓存。

对该 URL 进行的任何后续调用，然后从 Varnishd 缓存中提供服务，都不涉及 Rails 堆栈。

这是正确的还是我离题了？

我的应用程序如何在特定页面更新时告诉 Varnishd 并反映其缓存存储中所做的任何更改？

Varnishd 是一个很好的选择吗？

感谢您的帮助-我知道这些是非常基本的问题，但是文档并没有说清楚（至少对我而言）。

4

4 回答 4

6

要进行动态缓存失效，您可以purge.url {some regexp}通过管理通道从应用程序服务器发送。例如，purge.url "^/some/page/$"。但是，在 Rails 中，使用PURGEHTTP 方法可能是最简单的。GET因此，您无需执行 HTTP ，而是PURGE针对相同的 URI 执行：

PURGE /some/page/ HTTP/1.0
Host: example.com

localhost除非您在配置中覆盖该请求，否则该请求必须来自该请求。

一些链接：

于 2011-01-06T01:12:25.830 回答
3

我建议阅读 Mark Nottingham 的 HTTP 缓存指南：http ://www.mnot.net/cache_docs/

为了使用带有缓存的反向代理，您需要在 http 响应中指定到期时间。当有新内容可用时，通常不可能“告诉”缓存服务器，因为该协议旨在通过互联网联合起来，当你有新的小猫图片时，你不希望告诉世界各地的服务器：- )

Rails 页面缓存根本不是一回事。这只是将工作卸载到 Web 服务器以静态地提供文件，但不涉及决策中的 http 协议。

警告：我应该指出我没有亲自尝试过 Varnish。这个答案是基于（我认为正确的）假设 Varnish 是一个 http 缓存反向代理。

于 2011-01-05T23:21:22.243 回答
2

页面缓存可能是您想要的。它会比 Varnish 更容易设置和维护。当您开始扩展到多个应用程序服务器时，使用反向代理进行缓存确实具有一些优势，因为您可以在单个位置而不是在每个应用程序服务器上使缓存无效。

您可以将 Varnish 配置为响应 HTTP PURGE 请求，当页面发生更改时，Rails 会告诉 Varnish。这是一个插件和文章。

于 2011-01-06T01:22:17.363 回答
1

正如 noodl 的回答中提到的，如果使用反向代理，通常会使页面过期超出您的控制范围。另一种方法是您需要管理过期将使用 rails页面缓存（请参阅第 1.1 节），这使得 rails 在第一次调用操作时将响应呈现到磁盘（进入公共目录），并且您可以使用您的前端网络服务器直接提供这些 html 文件。我为此使用 nginx，并有一个指令来提供任何存在的静态文件（通常是图像，但也适用于 html 页面，并通过正确的重写来解释 .html 扩展名）。使用由 rails 管理的缓存，您可以使自己过期，就像在指南页面上的示例中那样，当创建新项目时索引过期。

我的理解是，反向 http 代理的目的是在吞吐量非常高时提高性能，因为它允许缓存传播到您无法控制的网络部分，但是如果它是您建议的渲染时间，那么轨道页面缓存对你来说可能是一个不错的选择。

于 2011-01-06T01:02:40.680 回答