之前的 2 个 Heroku 应用程序堆栈带有一个 Varnish 层，它会根据 http 标头自动反向代理缓存内容。
新的 Heroku cedar 堆栈没有这个 Varnish 层。 Heroku 建议改用rack-cache 和memcache。
与以前的带有清漆层的堆栈相比，这是否有缺点？使用 rack-cache，服务缓存层的服务器不是更少，而且优化的方式也更差吗？
【问题讨论】：
标签： heroku varnish rack-cache
毫无疑问，从 Heroku 的竹子堆栈到雪松堆栈，删除清漆层会大幅降低缓存性能（延迟和吞吐量）。一方面，您的应用程序请求正在与测功时间的缓存命中竞争，并且可能排在后面。
仅举几例，缺点是： 解释 ruby（相对于编译 C） 应用程序级（相对于代理级） 基于 memcached（相对于基于进程内存） 基于阻塞 I/O（相对于非阻塞 I/基于 O)。任何关于这两种缓存策略可以大规模竞争的建议都是荒谬的。你不会在小范围内看到太大的差异。但是，如果您每秒有数百甚至数千次缓存命中，varnish 不会显着降低，而 cedar 堆栈将需要许多 dyno 才能以高性能方式为静态资产提供服务。 （我看到 cedar 上的缓存命中需要 5-10 毫秒的测功机处理时间）。
Cedar 的构建方式不是为了提高性能，而是为您的应用程序引入新级别的灵活性。虽然它允许您执行长轮询等非阻塞 I/O 操作，以及对静态资产缓存参数的细粒度控制，但很明显，如果您的目标是互联网规模，heroku 希望您提供自己的缓存/带宽。
【讨论】：
我不知道在原始请求方面机架缓存性能与 Varnish 相比如何。最好的办法是创建一个简单的应用基准测试并切换堆栈。
值得记住的是，因为 heroku.com 堆栈是 Nginx->Varnish->App，只要您设置了正确的 HTTP 标头，您的 App 层的工作量就会少得多。由于大部分交付将由 Varnish 处理，而且 Varnish 的速度非常快，这可以让您的 Dyno 腾出时间来处理实际的应用程序处理请求。
随着 herokuapp.com 堆栈较早地访问您的应用程序，您和您的应用程序可以有效地处理缓存，这可能意味着您选择使用 rack-cache 来缓存整页输出，或者您可以选择使用 memcached 来处理与数据库请求或两者兼而有之。
最终，这取决于您的应用在做什么，如果它为许多用户提供相同的静态内容，那么您将从 Varnish 中受益，但如果您有一个用户登录并与内容交互的应用那么您将看不到 Varnish 可能会受益，因此缓存部分内容或原始数据库查询可能会更有效。如果您安装了New Relic addon，您将能够窥探底层，看看是什么让您的应用程序变慢了。
【讨论】：
托管 Varnish 也有 3rd 方选项。我写了一篇关于使用 Fastly/Varnish 进行设置的快速帖子。
Fastly 是一个托管的 Varnish 解决方案，它将位于您的 Heroku 应用程序前面并提供缓存的响应。
更新链接： https://medium.com/@harlow/scale-rails-with-varnish-http-caching-layer-6c963ad144c6
我已经看到了非常好的响应时间。如果您可以使用 Varnish 获得良好的缓存命中率，您应该能够降低您的测功机的很大一部分。
【讨论】：
一个更现代的答案，20/20 事后诸葛亮：
为了在 cedar-14 上获得接近竹子的缓存性能，这是通常的模式：
如果您在多个层（FE (CF/FY)、页面、动作、片段等）进行缓存，我建议将 redis-rails 作为机架缓存后端。
【讨论】：