Interesting interview with Alex Payne from the Twitter development team. He says that Twitter’s scalability issues are in part due to the fact that Ruby and Rails are just slow. Here’s a taste:
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.
I think this is true and important, but it’s also an issue that will be resolved in due course if the popularity of Ruby and Rails continue to rise. At one time, Java was almost unacceptably slow. That has changed. That said, in a world where the amount of money it costs to power and cool server farms is becoming an issue for companies, running on a platform that requires more wattage than another will make a difference.
It’s also worth noting that most applications are not Twitter, they’ll have relatively few users and can comfortably run without performance issues in just about any environment.
I do wonder, though, if this kind of information is going to push some startups over to PHP or Java, even if they’d prefer the development efficiencies offered by Rails. As he mentions in the article, the longer you can put off being forced into using stupid scalability tricks the better off you are.
Update: Ruby on Rails creator DHH responds. His bottom line is that this is something that the Twitter developers themselves could help fix. I do think it’s pretty lame to leverage all of the development advantages of a platform to build your application and get it out there, and then lay all the blame on it when performance problems crop up. Ruby on Rails is not as old or as widely used as Java or PHP. There are risks.
April 12, 2007 at 3:30 pm
This is one area where PHP has excelled. And this presents a nice opportunity for Python to get some traction and gain wider acceptance.
I’m curious as to where the line is, though — between hobby sites and personal blogs and bigger “enterprise” applications.
I’m also curious how long it’s going to take DHH to respond (he seems to have an uncanny ability to track down negative Ruby/Rails comments on the web and refute them).
April 12, 2007 at 4:28 pm
Well, that didn’t take long =)
http://www.loudthinking.com/arc/000608.html
April 12, 2007 at 4:32 pm
What with Leopard and XCode 3 shipping with Ruby/Rails as one of the default frameworks… This has to be addressed sooner. Not later.
Twitter, thanks for crossing the line. Now, something will get done or Ruby/Rails will get tossed on the rubbish heap.
April 12, 2007 at 5:29 pm
I’d say that adoption of PHP or Java will not pick up, Groovy and Python/TurboGears or Python/Django might see more adoption… but performance-wise, PHP is not necessarily the better trade-off, nor has it “excelled” at performance. Anyway, PHP will cause you a lot of grief with all its problems and I think people are realizing that.
April 12, 2007 at 6:45 pm
@Jonas: “but performance-wise, PHP is not necessarily the better trade-off, nor has it “excelled” at performance.”
Eight or ten years ago, I never heard anyone saying PHP was particularly slow (unless it was a language war, Perl vs Python vs PHP sort of thing). I never heard that had the sort of scaling problems that Ruby/Rails seems to have.
Whereas there have been plenty of discussions and comments made about Ruby’s inherent slowness, and the difficulty of scaling Rails “out of the box.” And these comments are coming from people looking at the thing as a standalone technology, without too many comparisons and language war stuff. You see enough of it, and you have to figure there’s something to it, beyond the average geek with an axe to grind.
I do agree, though, that PHP has many many other factors that will cause grief, but at the same time the discussion wasn’t about that.
April 12, 2007 at 6:55 pm
DHH “response” reminds me of the early days of Rails development where you had to be part of the secret cabal to find out about performance/security issues, and a party line of universal positivity was strictly enforced. I’m glad those days are gone.
April 12, 2007 at 7:22 pm
Umm…how about ASP.NET? Wicked scalability and performance.
April 12, 2007 at 7:23 pm
@Rebort: as PHP applications without an engine optimizer have to pull in the full script code at each request, even if you leverage the OS’ hdd-io-cache the script’s parsing time becomes a major performance factor for each request, especially with “massive” CMSs like Drupal or eZ. PHP’s design choices force this problem and I’ve seen a lot of performance-problems because of it.
Granted, the execution-speed after the code is pulled in is highly optimized by now. Essentially PHP is today where Ruby will certainly be in two years time.
So: you’re right. If someone had to make a decision based solely on performance of an implementation of his system, he’d be better off going with PHP.
Still, I think that the expectation of an uptake of Java or PHP from this discussion can only be maintained if you limit the discussion to performance. Because if you factor in all the problems that these platforms have, Ruby will come out ahead by a mile.
Not to mention that someone who works in Ruby will never ever switch to the pseudo-OOP-no-namespaces-mess that is PHP.
Anyway… it’s fun to watch 😉
April 12, 2007 at 8:23 pm
@Jonas — good points all around and I agree.
(I also laughed out loud at your “Not to mention that someone who works in Ruby will never ever switch to the pseudo-OOP-no-namespaces-mess that is PHP.” comment. It’s too true. =D )
April 13, 2007 at 11:37 am
@Jonas,
I worked in a Ruby on Rails shop and I’m going to pick up PHP and dump Ruby soon.
Why? Well… why not? There are tons of PHP jobs out there, tons of PHP freelance jobs, tons of “please drupal’ed my website”, tons of “please fix my php”
Flickr, Last.fm, Yahoo!, WordPress, Joomla, Drupal, Apache+MySQL support toward PHP.
One common theme I heard a lot in my shop was “Well.. whatever DHH thinks…chuckles… “.