21

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

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

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

4

4 回答 4

17

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

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

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

于 2012-02-17T00:25:39.183 回答
9

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

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

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

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

于 2011-11-08T10:40:41.280 回答
3

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

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

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

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

于 2013-10-10T02:24:15.847 回答
1

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

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

  1. 配置 Rails以生成适当的缓存标头（即 Etags、Cache-Control、Last-Modified 等）
  2. 在您的应用程序前面快速粘贴（清漆即服务）或cloudflare。如果应用标头设置正确，则不会缓存需要更新的类似配置文件的页面，而不是静态资产。

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

于 2015-02-17T05:44:48.820 回答