4 ms·

This is exactly why I started to use rails recently. If it becomes pretty easy to cache everything and you get the amazing productivity boosts that rails provid

This is exactly why I started to use rails recently. If it becomes pretty easy to cache everything and you get the amazing productivity boosts that rails provides you then there's really no down side. My first rails app is approaching 4k lines of code and responses that are cached using fragment caching are rendered in 5-8ms usually on a micro EC2 instance (aka. really bad hardware). I'm using MRI with rails 4.0.1 and I have not done any tweaking. Just basic caching that was trivial to implement and running rails in production mode which is just setting an ENV variable.

anonyfox 13y ago
You'll encounter the downsides when you have to do some serious number-crunching or analytical queries. Or just highly dynamic views that aren't cache-able. But that's not rails' fault, we all know that ruby itself isn't the fastest language to develop in, the "bloat" of rails just increases this a little. As long as you have enough cheap hardware to throw at all these problems, everything should be fine, though.
- rartichoke 13y ago
  I'm not too afraid of number crunching because if I do need some type of analytical report crunching done I'll just chuck them in a sidekiq worker and use the whenever gem to setup a cron job. I already setup sidekiq to work with e-mails and have whenever being used to generate a new sitemap once a day. And tbh I don't think I'll ever go too crazy with highly custom analytical queries either because google analytics is quite strong with custom event trackers and tools like new relic are excellent for system health and performance metrics. As for highly dynamic views that can't be cached then I would worry about them when the time comes. Maybe there's a way to setup varnish or nginx with SSIs to deal with that, it's something I never researched in depth but have to assume is a solved problem at this point with a little elbow grease and technical knowledge.

anonyfox 13y ago

You'll encounter the downsides when you have to do some serious number-crunching or analytical queries. Or just highly dynamic views that aren't cache-able. But that's not rails' fault, we all know that ruby itself isn't the fastest language to develop in, the "bloat" of rails just increases this a little. As long as you have enough cheap hardware to throw at all these problems, everything should be fine, though.

rartichoke 13y ago
I'm not too afraid of number crunching because if I do need some type of analytical report crunching done I'll just chuck them in a sidekiq worker and use the whenever gem to setup a cron job. I already setup sidekiq to work with e-mails and have whenever being used to generate a new sitemap once a day. And tbh I don't think I'll ever go too crazy with highly custom analytical queries either because google analytics is quite strong with custom event trackers and tools like new relic are excellent for system health and performance metrics. As for highly dynamic views that can't be cached then I would worry about them when the time comes. Maybe there's a way to setup varnish or nginx with SSIs to deal with that, it's something I never researched in depth but have to assume is a solved problem at this point with a little elbow grease and technical knowledge.