Over at the EngineYard blog, they have a couple of posts on working with RoR apps at scale, on general scaling and on sharding your database. We’ve had to do a few of these things already for certain customers and will hopefully have to do more in the future, but I think one of the important takeaways is that you shouldn’t do any of these things before you actually have a need to.
Almost all optimizations for performance are going to introduce some amount of friction in your development process and possibly add failure points, as well — and if you have a solution that works right now, and is going to work for what you estimate the load to be over the next month or two (depending on your release cycle), then you have solved the problem you have right now, and should spend that time adding features or fixing bugs instead.
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%” — Donald Knuth
In a comment to the page, Gregg Pollack points to his screencasts on Scaling Rails — I haven’t watched them yet, but he had a good session on ActiveRecord at last year’s Lone Star Ruby Conference.
