I was pottering around Wikipedia as you do, and stumbled across a link to an interview with a Twitter (social network website) dev. I'm pragmatic about programming language choices, but I do hate hype. Here's the URL and a juicy quote which seems to cut through some of that:
Interview with Twitter Developer Alex Payne
"By various metrics Twitter is the biggest Rails site on the net right now. Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.
"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.
"None of these scaling approaches are as fun and easy as developing for Rails. 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.
"Itââ¬â¢s also worth mentioning that there shouldnââ¬â¢t be doubt in anybodyââ¬â¢s mind at this point that Ruby itself is slow. Itââ¬â¢s great that people are hard at work on faster implementations of the language, but right now, itââ¬â¢s tough. If youââ¬â¢re looking to deploy a big web application and youââ¬â¢re language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think itââ¬â¢s worth being frank that this isnââ¬â¢t one of those relativistic language issues. Ruby is slow."
Re:Yep
djberg96 on 2007-05-18T00:36:34
You figured out that Rails would have scalability problems after watching a 10 minute video?THAT'S AMAZAZING!!!
What do you think he means by this? That the high-level Rails API makes it hard to work with multiple read-only slave dbs?
The basic statement he's making -- that you have to use caching and replication to scale database access once you can't fit it on one machine anymore -- is not specific to Ruby or Rails. It's the same story in Perl, PHP, Java, etc.
Maybe what he's really getting at is that ActiveRecord generates inefficient SQL, or is just impossible to use in a multi-db scenario.
Re:"talk to more than one database"?
djberg96 on 2007-05-18T00:43:42
Read loudthinking.com for two followups by DHH to that post. I'd provide direct links, but they seem to be borked at the moment. Short answer: the multi-db connection "problem" was solved by Dr. Nic as a plugin shortly after.The fact that Rails doesn't scale to multiple cores is a Ruby issue, not a Rails issue, and one that's certainly not unique to Ruby.
http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster
