Varnishd 是与 Rails 一起使用的正确缓存解决方案吗？
我想在我们的 Web 应用程序上缓存由 Rails 堆栈呈现的完整页面（数千个页面），但不会经常更改。每个渲染的资源都非常昂贵。
我对 Varnishd 工作原理的理解是，当对 URL 进行初始调用时，Varnishd 将检查其缓存存储，会发生未命中，因此请求将传递到 Rails，然后将生成的结果页面添加到Varnishd 缓存。
任何对该 URL 进行的后续调用，然后从 Varnishd 缓存提供服务，Rails 堆栈都不涉及。
这是正确的还是我离题太远了？
如何让我的应用程序告诉 Varnishd 特定页面何时更新和更新？以反映其缓存存储中所做的任何更改？
Varnishd 是实现此目的的不错选择吗？
感谢您的帮助 - 我知道这些是非常基本的问题，但文档只是没有说清楚（至少对我来说）。
I want to cache full pages on our web application (thousands of pages) that are rendered by the Rails stack, but don't change very often. Each render is quite expensive in terms of resources.
My understanding of how Varnishd works is that when an initial call is made to a URL, Varnishd will check its cache store, a miss will take place and so the request will be passed through to Rails and resulting page which gets generated is then added to the Varnishd cache.
Any subsequent calls made to that URL and then served from the Varnishd cache, the Rails stack is not involved.
Is this correct or am I way off?
How can have my app tell Varnishd when a specific page has been updated & to reflect any changes made in its cache store?
Is Varnishd a good choice for this purpose?
Thanks for your help - I know these are very basic questions, but docs just don't make this clear (to me at least).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我建议阅读 Mark Nottingham 撰写的 HTTP 缓存指南：http://www.mnot.net/cache_docs/
为了使用带有缓存的反向代理，您需要在 http 响应中指定到期时间。当有新内容可用时，通常不可能“告诉”缓存服务器，因为该协议旨在通过互联网进行联合，并且当您有新的小猫图片时，您不会希望必须告诉世界各地的服务器：- )
Rails 页面缓存根本不是一回事。这只是将工作卸载到 Web 服务器以静态地提供文件，但在决策中不涉及 http 协议。
警告：我应该指出，我个人还没有尝试过 Varnish。这个答案基于（我认为正确的）假设，即 Varnish 是一个 http 缓存反向代理。
I recommend reading this guide to HTTP caching by Mark Nottingham: http://www.mnot.net/cache_docs/
In order to use a reverse proxy with caching you'll need to specify expiry times in your http responses. It's generally not possible to "tell" the caching server when new content is available because the protocol is meant to be federated across the internet and you wouldn't want to have to tell servers everywhere in the world when you have new kittin pictures :-)
Rails page caching isn't the same thing at all. That just offloads the work to the web server to serve the files statically but doesn't involve the http protocol in the decision.
Caveat: I should point out that I haven't tried Varnish personally. This answer is based on the (I think correct) assumption that Varnish is a http caching reverse proxy.
页面缓存可能是您想要的。它比 Varnish 更容易设置和维护。当您开始扩展到多个应用程序服务器时，使用反向代理进行缓存确实具有一些优势，因为您可以在单个位置而不是在每个应用程序服务器上使缓存失效。
您可以将 Varnish 配置为响应 HTTP PURGE 请求，这将让 Rails 在页面发生更改时通知 Varnish。这是一个 插件 和 文章 就是这样的。
Page caching is what you probably want. It's going to be simpler to setup and maintain than Varnish. Caching with a reverse proxy does have some advantages when you start to scale to multiple application servers, since you can invalidate the cache in a single place instead of on each application server.
You can configure Varnish to respond to an HTTP PURGE request which will let Rails tell Varnish when a page has changed. Here's a plugin and article along those lines.
正如 noodl 的回答中提到的，如果使用反向代理，通常会使页面过期超出您的控制范围。另一种方法是您需要管理过期，即使用 Rails 页面缓存（请参阅第 1.1 节） ），这使得 Rails 在第一次调用操作时将响应渲染到磁盘（进入公共目录），并且您可以使用前端 Web 服务器直接提供这些 html 文件。我为此使用 nginx，并有一个指令来提供任何存在的静态文件（通常是图像，但也适用于 html 页面，并正确重写以考虑 .html 扩展名）。通过 Rails 管理的缓存，您可以自行过期，就像指南页面上的示例中那样，当创建新项目时索引就会过期。
我的理解是，反向 http 代理旨在当吞吐量非常高时提高性能，因为它允许缓存传播到您无法控制的网络部分，但是如果渲染时间如您所建议，那么 Rails 页面缓存对你来说可能是一个不错的选择。
As mentioned in noodl's answer, if using a reverse proxy, that generally makes page expiry something out of your control. An alternative approach is you will need to manage expiry would be to use rails page caching (see section 1.1), this makes rails render the response to disk (into the public directory) the first time an action is called, and you can use your front end webserver to directly serve those html files. I use nginx for this, and have a directive to serve any static files that exist (typically images, but works for html pages too with the correct rewrite to account for .html extension). With the cache managed by rails, you can then expire yourself, like in the example on the guides page there expiring an index when a new item is created.
My understanding is that reverse http proxies are intended for, and help performance when you have very high throughput, since it allows the caches to propagate to parts of the network outside your control, however if it's render time as you suggest, then rails page caching might be a good option for you.
要进行动态缓存失效，您可以通过管理通道从应用程序服务器发送
purge.url {some regexp}。例如，purge.url“^/some/page/$”。然而，在 Rails 中，使用PURGEHTTP 方法可能是最简单的。因此，您无需执行 HTTPGET，而是针对同一 URI 执行PURGE：此请求必须来自
localhost，除非您覆盖配置中的内容。一些链接：
To do dynamic cache invalidation, you can send
purge.url {some regexp}from your application server over the management channel. For example,purge.url "^/some/page/$". However, from Rails, it's probably easiest to use thePURGEHTTP method. So instead of doing an HTTPGET, you'd do aPURGEagainst the same URI:This request has to come in from
localhostunless you override that in the configuration.Some links: