4 ms·

For what it's worth, apparently the Basecamp team was hitting ~50ms request times with their new (well, now it's not that new) design: http://37signals.com/svn/

For what it's worth, apparently the Basecamp team was hitting ~50ms request times with their new (well, now it's not that new) design: http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui http://37signals.com/svn/posts/3112-how-basecamp-next-got-to... All technology has its trade-offs. Rails can be plenty fast, it just all depends on how you're using it.

anonyfox 13y ago
It'ns not that Rails is that fast (it isn't), they simply cache every damned piece upfront. When your requests barely ever touch the rails but are satified from the cache, you can use nearly everything as your backend stack.
- rartichoke 13y ago
  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

It'ns not that Rails is that fast (it isn't), they simply cache every damned piece upfront. When your requests barely ever touch the rails but are satified from the cache, you can use nearly everything as your backend stack.

rartichoke 13y ago
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.