4 ms·
Rails scales just fine - the problem is that it's just really expensive to do it. Here's some of our learnings: 1. Use query_trace to trace your DB calls and
by blader 18y ago
Rails scales just fine - the problem is that it's just really expensive to do it.
Here's some of our learnings:
1. Use query_trace to trace your DB calls and query_analyzer to automatically run EXPLAIN on each call:
http://github.com/ntalbott/query_trace/tree/master http://github.com/ntalbott/query_trace/tree/master
http://github.com/jeberly/query-analyzer/tree/master http://github.com/jeberly/query-analyzer/tree/master
2. Use our patches to mongrel proc_title to troubleshoot slow queries: http://asemanfar.com/Request-Queue-via-Mongrel-Proctitle http://asemanfar.com/Request-Queue-via-Mongrel-Proctitle
3. Don't use ActiveRecord.
4. Don't use any link or url helpers in Rails.
5. For that matter, don't use Rails. Rewrite your most hit components in something faster.
I love Ruby, but the simple truth of it is that we'd be saving a couple of engineer's worth of money if we weren't on Rails.
- rantfoil 18y agoI dunno about saving a couple engineer's worth of money -- that's why Rails is massively viable in the first place. You absolutely can iterate faster with fewer people and less wasted time. Servers are cheap. People (salaries) are expensive. (Well.. until servers become expensive due to straight up load/scale, that is.)
- blader 18y agoRight now we're estimating that our Rails premium = 4X the salary of a San Francisco engineer. But we do have a lot of servers.