Heroku cedar 堆栈中机架缓存与 Varnish 的缺点?
之前的 2 个 Heroku 应用程序堆栈带有一个 Varnish 层,它会根据 http 自动反向代理缓存内容标头。
新的 Heroku cedar stack 没有这个 Varnish 层。 Heroku 建议使用 rack-cache 和 memcache 代替。
与之前带有清漆层的堆栈相比,这是否有缺点?使用机架缓存,为缓存层提供服务的服务器是否会更少,并且优化程度也较低?
The previous 2 Heroku application stacks came with a Varnish layer which automatically reverse-proxy-cached content based on http headers.
The new Heroku cedar stack doesn't have this Varnish layer. Heroku suggests using rack-cache and memcache instead.
Does this have disadvantages compared to the previous stacks with the varnish layer? With rack-cache, aren't there fewer servers serving the caching layer, and in a less optimized way?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
毫无疑问,从 Heroku 的竹子堆栈到雪松堆栈,删除清漆层会导致缓存性能(延迟和吞吐量)大幅下降。其一,您的应用程序请求会与缓存命中竞争动态时间,并且可能会在缓存命中后面排队。
仅举几例,其缺点包括: 解释型 ruby(与编译型 C 相比) 应用程序级别(与代理级别) 基于 memcached(与基于进程内内存) 基于阻塞 I/O(与基于非阻塞 I/O) 。任何认为这两种缓存策略可以大规模竞争的说法都是荒谬的。在小范围内你不会看到太大的差异。但是,如果每秒有数百甚至数千次缓存命中,varnish 不会显着降低性能,而 cedar 堆栈将需要许多测功机才能以高性能方式提供静态资源。 (我看到 cedar 上的缓存命中的动态处理时间约为 5-10ms)。
Cedar 的构建方式不是为了提高性能,而是为了为您的应用程序引入新级别的灵活性。虽然它允许您执行非阻塞 I/O 操作(例如长轮询)以及对静态资产缓存参数的细粒度控制,但很明显,如果您的目标是互联网规模,heroku 希望您自带缓存/带宽。
There is absolutely no question that removing the varnish layer is a huge downgrade in cache performance -- both latency and throughput -- from Heroku's bamboo to cedar stack. For one, your application requests are competing with, and may be queued behind, cache hits for dyno time.
The disadvantages, to name a few, are: interpreted ruby (vs. compiled C) application level (vs. proxy level) memcached based (vs. in process memory based) blocking I/O based (vs. nonblocking I/O based). Any suggestion that the two caching strategies could compete at scale is ridiculous. You won't see much difference on a small scale. But if you have hundreds or even thousands of cache hits per second, varnish will not substantially degrade, while the cedar stack would require many dynos just to serve static assets in a performant fashion. (I'm seeing ~ 5-10ms dyno processing time for cache hits on cedar).
Cedar was built the way it was built not to improve performance, but to introduce new levels of flexibility over your application. While it allows you to do non blocking I/O operations like long polling, and fine grained control over static asset caching parameters, it's clear that heroku would like you to bring your own caching/bandwidth if your goal is internet scale.
我不知道在原始请求方面机架缓存性能与 Varnish 相比如何。最好的选择是创建一个简单的应用程序基准测试并切换堆栈。
值得记住的是,因为 heroku.com 堆栈是 Nginx->Varnish->App,只要您设置了正确的 HTTP 标头,您在 App 层所做的工作就会少得多。由于大部分交付将由 Varnish 处理,而且 Varnish 速度相当快,这可以让您的 Dyno 腾出时间来处理实际的应用程序处理请求。
随着 herokuapp.com 堆栈更早地访问您的应用程序,有效处理缓存取决于您和您的应用程序,这可能意味着您选择使用机架缓存来缓存整页输出,或者您可能选择使用 memcached 来处理数据库请求或两者兼而有之。
最后,这取决于你的应用程序在做什么,如果它为很多用户提供相同的静态内容,那么你会从 Varnish 中受益,但如果你有一个用户登录并与内容交互的应用程序,那么你就赢了't see 可能会受益于 Varnish,因此缓存部分内容或原始数据库查询可能会更有效。如果您安装 New Relic 插件,您将能够在引擎盖下看一眼并看到是什么导致你的应用程序变慢。
I don't know how the rack-cache performance compares to Varnish in terms of raw requests. The best bet would be to create a simple app benchmark it and switch stacks.
It's worth bearing in mind that because the heroku.com stack was Nginx->Varnish->App as long as you've set the correct HTTP headers you're App layer will be doing much less work. As most of the delivery will be handled by Varnish, as well as Varnish being pretty fast, this frees up your Dyno for actual app-handling-requests.
With the herokuapp.com stack hitting your app earlier, it's down to you and your app to handling caching efficiently, this might mean you choose to use rack-cache to cache full page output or you might choose to use memcached to deal with database requests or both.
In the end it depends on what your app is doing, if it's serving the same static content to a lot of users then you'd benefit from Varnish, but if you've got an application where users login and interact with content then you won't see might benefit from Varnish so caching partial content or raw database queries might be more efficient. If you install the New Relic addon you'll be able to take a peek under the hood and see what's slowing your app down.
还有托管 Varnish 的第 3 方选项。我写了一篇关于使用 Fastly/Varnish 设置它的快速文章。
Fastly 是一个托管的 Varnish 解决方案,它将位于您的 Heroku 应用程序前面并提供缓存的响应。
更新链接:
https://medium.com/@harlow/ scale-rails-with-varnish-http-caching-layer-6c963ad144c6
我看到了非常好的响应时间。如果你能用 Varnish 获得良好的缓存命中率,你应该能够降低你的 dyno 的很大比例。
There are also 3rd party options for hosted Varnish. I wrote a quick post about setting it up with Fastly/Varnish.
Fastly is a hosted Varnish solution that will sit in front of your Heroku app and serve cached responses.
Update link:
https://medium.com/@harlow/scale-rails-with-varnish-http-caching-layer-6c963ad144c6
I've seen really great response times. If you can get a good cache hit-rate with Varnish you should be able to throttle back a good percentage of your dyno's.
一个更现代的答案,20/20 后见之明:
为了让缓存性能接近 cedar-14 上的竹子,这是通常的模式:
如果您要在多层(FE (CF/FY)、页面、操作、片段等)进行缓存,我会推荐 redis-rails 作为机架缓存后端。
A more modern answer, with 20/20 hindsight:
To get the caching performance approaching that of bamboo on cedar-14, this is the usual pattern:
I would recommend redis-rails as a rack cache backend, if you're doing caching at multiple layers (FE (CF/FY), page, action, fragment, etc.).