Jeff Croft

I’m a product designer in Seattle, WA. I recently worked at Simply Measured, and previously co-founded Lendle.

Some of my past clients include Facebook, Microsoft, Yahoo, and the University of Washington.

I’ve authored two books on web and interactive design and spoken at dozens of conferences around the world.

I’m currently accepting contract work and considering full-time opportunities.

Link // 04.12.2007 // 4:18 PM // 9 Comments

Interview with Twitter Developer Alex Payne

Alex has a lot to say about Twitter, Rails, and scaling. Not to Rails-bash, but it’s hard to ignore these quotes:

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.


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.

Props to Alex for being upfront and forward and not sticking to the Rails party line of “it’s fast enough.” Alex is obviously in a unique situation, as Twitter is the biggest Rails app on the web. Rails, which is a great framework in so many ways, will probably work great for your site, which is almost certainly not as intensive as Twitter.

But until the performance can scale to a huge site, people are always going to be a bit scared to use it for a startup they perceive as “the next big thing.”

Visit site...


  1. 001 // Kyle // 04.12.2007 // 2:39 PM

    I’d also like to point out David’s response:…

    I read Alex’s interview and couldn’t help but choke a little bit. Twitter hasn’t exactly been the most upfront about it’s development — from it’s shady crashing starts, to it’s message-eating status right now.

    Twitter is under the false assumption that they can handle a load like 11,000 req/s off one box with no caching. I’m not sure where that thought ever crossed their mind, but I suppose that’s their deal.

    The problem is that they are blaming the technology for their own faults. If you build an application in any language, hit 11,000 req/s, with little to no caching, you’re going to hurt.

    I think a great counter-point to Twitter’s development team is a team like the Robot Co-op (of 43things, etc), who have sustained extremely large loads on Rails without complaining or blaming technology.

  2. 002 // Jeff Croft // 04.12.2007 // 3:55 PM

    If you build an application in any language, hit 11,000 req/s, with little to no caching, you’re going to hurt.

    While this is almost certainly true, it doesn’t change the fact that Ruby is damn slow compared to the alternatives, and it also doesn’t change the fact that in order to speed it up, you sometimes have to forgo the things that drew you to Rails in the first place.

    I think a great counter-point to Twitter’s development team is a team like the Robot Co-op (of 43things, etc), who have sustained extremely large loads on Rails without complaining or blaming technology.

    They have, but you and I both know that 43things doesn’t do anywhere near the traffic of Twitter.

    I’m not familiar enough with Rails to know whether it can handle a site of Twitter’s traffic with the right hardware or not — but I am familiar enough with a certain Python-based framework to know that it is possible in other languages.

    Everyone knows that Ruby is slow as hell compared to other similar languages. That’s a fact, wether it’s the cause of Twitter’s issues or not.

  3. 003 // Dan // 04.12.2007 // 4:29 PM

    I don’t think Alex was necessarily blaming the technology or making excuses. He just seems to be pointing out the challenges they had/have.

  4. 004 // Kyle // 04.12.2007 // 5:36 PM

    Jeff: I think you’re kind of side-stepping the issue though. If you read David’s letter, he’s pointing out that by choosing a technology/framework/etc it’s a matter of it’s particular strengths and weaknesses. Whether or not you first hit your bottleneck at the application level, or hit it at the database level, you’re going to hit it somewhere along the line. Blaming the technology isn’t going to help, and you’re probably going to have to get your hands dirty somewhere along the line.

    Also, I wouldn’t be so quick to judge the Robot co-op. I know last year they were doing 2.5 million requests (not including static files) a day [link]. It’s very possible they’ve had surges in the twitter range.

    I know that I’ve been involved with dozens of J2EE (a language that is clearly “proven” as scalable) sites that have hit barriers like this at a lot lower traffic levels. I’d be willing to bet that no matter the language Twitter chose, they’d hit the same problems (perhaps not at the specific level they’re describing now, but somewhere along the line).

  5. 005 // David Sissitka // 04.13.2007 // 2:41 AM

    If you’re going to quote Alex Payne you cannot forget this gem:

    I tried to speak in clear and balanced language in that interview, but clearly I didn’t accomplish as much. Thankfully, the only person I’ve seen take my comments as a wholesale rejection of Rails was Adrian Holovaty of the Django project. We’d be running into scaling issues on Django or any other platform. We’re happiest scaling on Rails.

    According to Statsaholic 43things was about 1/3 the size of Twitter, can you name one Django based site that is the size of 43things?

  6. 006 // Jeff Croft // 04.13.2007 // 9:21 AM

  7. 007 // David Sissitka // 04.13.2007 // 11:27 AM

    Wow, according to Statsaholic The Washington Post website sees even more traffic than Twitter. I hope that The Washington Post website is featured in the case studies section of th Django book.

  8. 008 // Deryck Hodge // 04.13.2007 // 1:57 PM

    For the sake of accuracy, itself doesn’t run on Django. There are lots of individual apps or projects on as well as at Newsweek and Slate (which are run by the same company) that do run on Django.

    I’ve seen lots of traffic at Washington Post/Newsweek, and Django/Python/mod_python/Posgtesql performs well. 11,000 hits a second is a lot of traffic, though. I’ve had apps linked from MSN, MSNBC, and all on the same day, and I didn’t see those numbers. (More like 1,000-1,500 hits a second range.) Keep in mind that just over 100 hits a second is 10 million hits a day. 11,000 is a lot of traffic and would cause any setup issues.

    Having said that, I survived the measly-by-comparison ;-) 1000 hits-a-second traffic with two load balanced web servers and a single database, so I don’t think it’s hard to see that Django/Python/mod_python/Postgresql would scale out well above that. Probably, much easier than the pain Alex describes.

  9. 009 // Manuel // 04.13.2007 // 4:36 PM

    Twitter developers have just discovered what I call Raillusion.

    Rails is based on the simple assumtion that the savings in development time/cost are much greater than the additional cost for hardware/hosting you will have to sustain to support a slow framework written in a slow language.

    This assumption has many flaws.

    Development cost is generally a one-time expense and, in force of the current glut of good programmers around the world, this cost is not that high. On the other hand, hardware/hosting costs could turn into an heavy burden if your site gets a lot of visitors. At some point you will be forced to rewrite large parts of your app in other faster languages to eliminate major bottlenecks. As a consequence Rails is a great thing if your site remains a small/medium one but if you really succeed in the marketplace Rails will become a problem… In fact Rails scales but the cost is simply prohibitive.

    However, considering that most startups fail, developing with Rails could be a good strategy to minimize the initial investment.

    At any rate Rails is not the only web-framework on earth…

    Python frameworks are currently a lot faster than Rails. Why? 1) Python is currently faster than Ruby 2) Many Python frameworks (see Django) were designed with performance as a priority. Moreover these frameworks retain the same productivity advantages Rails claims. In other words they are a safer bet at the moment.

Tags for this link