Dec
12
Scaling in Rails
Original post by Mike Bukhin on see a puffin eat a fish
11:11 am | Categorized: Code, Designing for Constraints, ITP 2007 (i)

My friend Claude pointed me to this interview with the Twitter developers regarding their Rails scaling issues. Not surprisingly, you can throw as many web instances at your site as you want but the real bottleneck ends up being the database. Then you end up having to deal with Squid, real time replication and read-only child databases. Suddenly you need an IT team.
“All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.”
Indeed. When I tail my development.log and look at the SQL being generated by Rails, it makes me cringe. I know i’ll have to one day do something about it but i’m putting it off as long as possible because i’d rather preserve the illusion of Rails (for now anyway) and not clutter my code with three table joins.
Also, check out this snarky response to the Rails developers.