Heroku cedar 堆栈中 rack-cache 与 Varnish 的缺点？

Posted 2023-03-10

【中文标题】Heroku cedar 堆栈中 rack-cache 与 Varnish 的缺点？

【英文标题】：Disadvantages to rack-cache vs. Varnish in Heroku cedar stack?

【发布时间】：2011-12-17 10:15:14

【问题描述】：

之前的 2 个 Heroku 应用程序堆栈带有一个 Varnish 层，它会根据 http 标头自动反向代理缓存内容。

新的 Heroku cedar 堆栈没有这个 Varnish 层。 Heroku 建议改用rack-cache 和memcache。

与以前的带有清漆层的堆栈相比，这是否有缺点？使用 rack-cache，服务缓存层的服务器不是更少，而且优化的方式也更差吗？

http://devcenter.heroku.com/articles/http-routing http://devcenter.heroku.com/articles/http-caching http://devcenter.heroku.com/articles/cedar

【问题讨论】：

如果你使用的是 Rails > 3.1，你可以把你的静态资源放在一个竹栈应用程序上，这样你就可以享受 Varnish 的好处，而把剩下的留给 Cedar 应用程序。或者您可以将它们放在此处描述的 CDN 上：devcenter.heroku.com/articles/cdn-asset-host-rails31

【参考方案1】：

毫无疑问，从 Heroku 的竹子堆栈到雪松堆栈，删除清漆层会大幅降低缓存性能（延迟和吞吐量）。一方面，您的应用程序请求正在与测功时间的缓存命中竞争，并且可能排在后面。

仅举几例，缺点是： 解释 ruby​​（相对于编译 C） 应用程序级（相对于代理级） 基于 memcached（相对于基于进程内存） 基于阻塞 I/O（相对于非阻塞 I/基于 O)。任何关于这两种缓存策略可以大规模竞争的建议都是荒谬的。你不会在小范围内看到太大的差异。但是，如果您每秒有数百甚至数千次缓存命中，varnish 不会显着降低，而 cedar 堆栈将需要许多 dyno 才能以高性能方式为静态资产提供服务。 （我看到 cedar 上的缓存命中需要 5-10 毫秒的测功机处理时间）。

Cedar 的构建方式不是为了提高性能，而是为您的应用程序引入新级别的灵活性。虽然它允许您执行长轮询等非阻塞 I/O 操作，以及对静态资产缓存参数的细粒度控制，但很明显，如果您的目标是互联网规模，heroku 希望您提供自己的缓存/带宽。

【参考方案2】：

我不知道在原始请求方面机架缓存性能与 Varnish 相比如何。最好的办法是创建一个简单的应用基准测试并切换堆栈。

值得记住的是，因为 heroku.com 堆栈是 nginx->Varnish->App，只要您设置了正确的 HTTP 标头，您的 App 层的工作量就会少得多。由于大部分交付将由 Varnish 处理，而且 Varnish 的速度非常快，这可以让您的 Dyno 腾出时间来处理实际的应用程序处理请求。

随着 herokuapp.com 堆栈较早地访问您的应用程序，您和您的应用程序可以有效地处理缓存，这可能意味着您选择使用 rack-cache 来缓存整页输出，或者您可以选择使用 memcached 来处理与数据库请求或两者兼而有之。

最终，这取决于您的应用在做什么，如果它为许多用户提供相同的静态内容，那么您将从 Varnish 中受益，但如果您有一个用户登录并与内容交互的应用那么您将看不到 Varnish 可能会受益，因此缓存部分内容或原始数据库查询可能会更有效。如果您安装了New Relic addon，您将能够窥探底层，看看是什么让您的应用程序变慢了。

【讨论】：

好的，你已经证实了我的怀疑，应用程序 dyno 正在做服务缓存而不是独立层的工作（这很明显，但在 heroku 文档中根本没有提到所以我想确认）。

@Tom - “您选择使用 rack-cache 来缓存整页输出，或者您可以选择使用 memcached 来处理数据库请求或两者兼而有之。”将使用哪些命令来指定应通过 rack-cache 与 memcached 服务的页面？如果我执行“caches_action :show”，它会进入 rack-cache 还是 memcached？同样，如果我执行 Rails.cache.fetch ... 是否会同时使用 Memcached 获取元信息和实体信息？有没有办法使用 Rack-cache 来存储 rails.cache.fetch 的结果，这样我就不会用实体信息（即仅元数据）填充我的内存缓存？

@Brandon 可能会更好地提出一个新问题，认为 rack-cache 和 rails.cache.fetch 的行为不同，我当然不是 Rails 专家 :)

@Tom 感谢您的回复！到目前为止，我已经尝试过separate question，但运气不佳，所以尝试四处寻找:)如果您确实知道有人可以回答这个问题，如果您能传给我，我将不胜感激。

【参考方案3】：

托管 Varnish 也有 3rd 方选项。我写了一篇关于使用 Fastly/Varnish 进行设置的快速帖子。

Fastly 是一个托管的 Varnish 解决方案，它将位于您的 Heroku 应用程序前面并提供缓存的响应。

更新链接： https://medium.com/@harlow/scale-rails-with-varnish-http-caching-layer-6c963ad144c6

我已经看到了非常好的响应时间。如果您可以使用 Varnish 获得良好的缓存命中率，您应该能够降低您的测功机的很大一部分。

【讨论】：

我认为应该链接到medium.com/@harlow/… 吗？

【参考方案4】：

一个更现代的答案，20/20 事后诸葛亮：

为了在 cedar-14 上获得接近竹子的缓存性能，这是通常的模式：

ConfigureRails 生成适当的缓存标头（即 Etags、Cache-Control、Last-Modified 等） 在你的应用前面贴上fastly（清漆即服务）或cloudflare。如果应用标头设置正确，则不会缓存需要更新的类似配置文件的页面，而不是静态资源。

如果您在多个层（FE (CF/FY)、页面、动作、片段等）进行缓存，我建议将 redis-rails 作为机架缓存后端。