Link Details

Nice response. Took the words right out of my mouth...

I agree...its not just a rails thing. Forethought in your capacity planning helps no matter what language your using.

Posting my response here, since I put some time into it... but it's still friggin' "awaiting moderation" 5 days later. Ugh.
------------
I think LinkedIn knew what they were doing in choosing RoR for this application; their primary site runs on Java, and has to scale even higher, but with more dynamic content. Java has upsides and downsides, though, and given that:
* they could design this application so that most page hits were static
* RoR very likely made development faster
…this was likely a good decision.

If the application could *not* be implemented as it was, and had higher requirements for the dynamically-generated portion, they might have chosen differently… though I don’t know, and I’d love to hear more from the LinkedIn engineers about this issue specifically.

A few other quick comments:
“Linkedin realized the only way to scale Rails was to use it as little as possible to serve their requests.”

That comes off a bit cruel, actually — Rails can scale with more hardware; it’s just always much cheaper overall to design an app to return more static pages than dynamic (this is true scaling Rails, PHP, Java, whatever). Inasmuch the dynamic portion needs to scale, though, performance does matter quite a lot, dollar-wise.

“Rails lack of performance makes you think about scaling earlier than you would on another platform. This is a GOOD thing.”

Huh… that’s like saying “no, credit cards with a HIGHER interest rate are better — that’ll force you to think earlier about staying out of debt.” It’s rationalization logic. Many webapps will never need to do any serious scaling. When they do, it costs money for the expertise, hardware, running costs, etc. etc.. Either way, smart developers will evaluate scaling options early on, regardless of platform. Being “forced” to do that isn’t actually helpful, just more expensive.

I’m sure you aren’t hoping for a next generation Rails interpreter that’s *slower* than what you have now, to be even more helpful.