Heroku雪松堆栈中机架缓存与清漆的缺点?

时间:2011-10-28 16:08:33

标签: heroku varnish rack-cache

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

新的Heroku雪松堆没有这个Varnish层。 Heroku建议改为使用rack-cachememcache

与以前使用清漆层的堆叠相比,这是否有缺点?使用机架缓存,服务于缓存层的服务器是否更少,并且采用不太优化的方式?

4 个答案:

答案 0 :(得分:17)

毫无疑问,从Heroku的竹子到雪松堆栈,移除清漆层是缓存性能(包括延迟和吞吐量)的巨大降级。例如,您的应用程序请求与dyno时间的缓存命中竞争,并且可能排在后面。

缺点,仅举几个例子,是:解释的ruby(与编译的C)应用程序级别(与代理级别)基于memcached(基于进程内存)基于阻塞I / O(与非阻塞I / O基础)。任何关于这两种缓存策略都可以大规模竞争的建议都是荒谬的。你不会在小范围内看到太大的差异。但是如果你每秒有数百甚至数千个缓存命中率,那么清漆就不会大幅降低,而雪松堆栈则需要许多dynos才能以高效的方式提供静态资产。 (我看到雪松上的缓存命中时间为5-10ms dyno处理时间。)

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

答案 1 :(得分:9)

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

值得注意的是,因为heroku.com堆栈是Nginx-> Varnish-> App,只要您设置了正确的HTTP标头,您的App层将会做更少的工作。由于大多数交付将由Varnish处理,以及Varnish非常快,这将释放您的Dyno以实际应用程序处理请求。

随着herokuapp.com堆栈更早地点击您的应用程序,这取决于您和您的应用程序有效处理缓存,这可能意味着您选择使用rack-cache来缓存整页输出,或者您可能选择使用memcached来处理有数据库请求或两者都有。

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

答案 2 :(得分:3)

托管的Varnish还有第三方选项。我写了一篇关于用Fastly / Varnish进行设置的快速文章。

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

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

我看到了非常好的响应时间。如果你能用Varnish获得一个很好的缓存命中率,你应​​该可以减少你的dyno的很大一部分。

答案 3 :(得分:1)

一个更现代的答案,20/20后见之明:

为了让cedar-14的缓存性能接近竹子,这是通常的模式:

  1. Configure Rails生成适当的缓存标头(即Etags,Cache-Control,Last-Modified等)
  2. 在您的应用前粘贴fastly(清漆即服务)或cloudflare。如果正确设置了应用程序标题,则不会缓存需要新鲜的类型的页面,而不是静态资产。
  3. 如果你在多层(FE(CF / FY),页面,动作,片段等)进行缓存,我建议使用redis-rails作为机架缓存后端。