I've considered this option now and then for my own website, specially after the recent Heroku announcement that the free plan couldn't be online 100% of the time. Basically, I'm not really interesting in spending money on my own site since I get nothing from my articles. I know there are cheap options out there but I simply believe it's not fair that I pay for writing articles for free...

So, since there aren't many Rails free alternative hosts out there, I often consider moving my site to a static one (I had some experience with Middleman in the past) because I would be able to host it in Github Pages, for example, for free and serve it really fast which is good for Google ranking, differently from Heroku using the free plan. But since it would require some effort, I'm still post-poning this move and even evaluating whether I'd prefer to pay for hosting instead of rewriting the site using a static generator tool... On the other side, it would be a good opportunity to review my site design and make it more mobile friendlier and less ugly...

Great write up, really interesting! I think performance is only one reason why some people prefer to generate static pages; simplicity ("I don't have to worry about anything, can pick any hoster, no DB, no cache, no nothing") is the other. But while static pages might scale from a technical stand point, they definitely don't scale when your company/organization grows. If there is only on slightly dynamic requirement you will have to throw away the whole page generation stack and move to Rails (or any other framework/cms).

They're similar but not the same. Rack-cache is a poor replacement for a real http cache such as Varnish. It will use the internal Ruby process' memory. It will require hitting the Ruby process. The Raptor cache comes before even hitting the Ruby process below it. As a result it can sustain higher throughout. I tried Puma + Rack-Cache and it can hold less than half of the load I put through Blitz.io before timing out and erroring out. So "pure" Rails < Puma + Rack-Cache < Raptor < Varnish, but as setting up Varnish in front of your app servers may not be particularly trivial, using Raptor, on the other hand requires little effort and works out of the box.

Yes, HTTP caching is really powerful. You say that you get the same performance for dynamic as for static pages, but it looks to me as though you cached that dynamic page, and are testing your performance against that cached version. Of course you will get the same performance then, because your dynamic template essential gets cached into a static HTML file.

Another thing, it seems that Passenger here acts as a reverse proxy. It has it's own cache, which it uses when appropriate. Isn't this what Nginx already does?

Of course, the performance is close exactly because the output is the same.

The difference is that you don't have to forego using a dynamic web framework and go straight to a static site generator just because of performance, that's the point.

Passenger implements something similar to Varnish, an internal cache that responds to headers such as Cache-Control and Vary and returns from the cache instead of hitting the app for such cases, which is why it is blazing fast for those situations.

I'm clear to state that this is not something to make Rails itself generally blazing fast, but to make content sections fast enough to mix with dynamic sections in the same app without the need to go out of the framework. That's it.

Thanks for choosing Memcached Cloud!

It's Garantia Data behind it, right? I always knew Garantia is one of the most reliable Redis providers.

Btw, I mentioned in the tests that the Puma + Rack-Cache didn't scale to the same load I applied with Passenger. One of the reasons was because Rack-Cache wasn't getting responses fast enough. However, I am using Memcache to cache AR objects and it's holding up.

I suppose there is limited number of connections or something like that. What would that be? (I'm using the free plan for the purposes of the demo).

Indeed, that is ours although we've changed our name to Redis Labs a while back (https://redislabs.com/blog/.... Thanks again for the great feedback :)

As for your question regarding the number of connections - there is no limit on that with Memcached Cloud, even with the free tier. I'd be glad to hook you up with our help desk to look into the performance issue.

Great writeup! Thanks for outlining this all, I'm looking forward to implementing some of the Passenger 5/ETag/Cache stuff in my apps. :)