Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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?
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.