Ruby is a really great language with some awesome features, and Rails make it even better. But it appears that it does not scale well yet. Twitter is a great example of using RoR to run a website with millions of users hitting your server few hundred times a day each. Amazingly enough, it seems to be running very smoothly lately, but they did have many rough spots in the last few months when the sites performance was really poor.
It seems that their issue is not the execution speed, but the Rails design itself. In a recent interview a Twitter developer Alex Payne said:
The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there’s no facility in Rails to talk to more than one database at a time. The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it’s not just cost, it’s time, and time is that much more precious when people can[’t]reach your site.
Emphasis was mine. The lack of support for multiple databases seems a huge bottleneck issue for high traffic sites. Most of us don’t even think about stuff like that when considering using a platform to build our applications with.
I still think RoR is a good platform. It just might not be ready for the enterprise scale apps like Twitter. Most of us however will never experience this issue – unless of course we get slashdotted or something. I’m confident that the Rails team will use the Twitter problems to improve scalability features in future releases.
[tags]ruby, ruby on rails, twitter, bottleneck[/tags]
i’m not a fan of rails — but a database cluster is the correct solution here. the way to have rails talk to multiple database is to have multiple rails apps. with gems, the code sharing works cleanly.
not sure how you’d “split” things otherwise at the model level. you can partition and play caching tricks, but that’s just delaying the inevitable.
due to concurrency issues only the database knows what needs to be updated and when. alex’s quote referencing “read-only slave databases” and “caching” indicates that he hasn’t really thought about the problem and is just another guy wrestling to make a half-complete system, complete.
Cal from Flickr wrote an O’Reilly book that outlines some of the problems, even if the solutions are a little “on the sly” by enterprise standards. still, it’s tough to argue with the results. though note that he talks at length about the amount of extra code they write that checks and double checks integrity of cache. and they’ve had some pretty bad caching bugs — porn pics showing up, etc.
a lot of this style of systems design is “okay for dopey web site” but not so good for financial or information systems design. whether or not this stuff works long term and ever scales up to “real” reliability remains to be seen.
Database cluster sounds about right. Although if you have a single master node ruining the actual database server, you still get in trouble. What you would ideally want is to have several nodes listening for connections.
But then you run into concurrency hell…
I heart the Rails community. Not only did Nic cure the database concurrency problems exposed in Rails by Twitter – he did it without being asked, he shared it with everyone (as a Rails plugin), and he did it in 75 lines of Ruby.
Word.
Wow! That was fast. Rails community really has it together. Thanks for sharing this!