Comment by aneth | Hacker News Reader

Comment by aneth | Hacker News Reader

Parent Full thread

I'm a 5 year + rails developer, and this doesn't actually surprise me. Ruby and Rails are just incredibly slow in my experience unless you cache everything, which can greatly increase complexity. Right now I'm struggling with the creation of 2000 active record objects taking 10 seconds, which is absolutely ridiculous. And that's down from 30 seconds - which was happening because require was being called for each of those object instantiations by a third party library. So a 20 second gain by removing 2000 calls to require - on Heroku - something is wrong there.

The JSON that's generated with all that data is converted to backbone objects instantaneously in a browser, and the few database calls are instantaneous - it's all Ruby. I will probably need to create custom lightweight objects just because ruby is so darn slow. Much of the time is spent in gsub resolving paths for paperclip attachments - work that would take most languages a few milliseconds can take 10 seconds in ruby. I know there are many ways to optimize this but I should not have to at this point.

I find with ruby I constantly run into performance bottlenecks and need to revert to optimization that I would not have to do on other platforms.

Yours is the typical answer from rails fans. But what could be wrong with his Rails implementation that could be that slow, assuming they are reasonably competent - a valid assumption I think given their successful port to node?

I find with ruby I constantly run into performance bottlenecks and need to revert to optimization that I would not have to do on other platforms.

Agree. Ruby tends to be more likely to be CPU-bound than other languages. That demands a more indepth understanding of Ruby itself. For example, as simple as string concatenation of use '+' vs '<<' can easily fail lots of people.

Yours is the typical answer from rails fans.

I don't quite like the tone of this statement. Although I've been working with Rails at work for the past five years, I don't consider myself a Rails fanboy. I consider it a valuable tool to bring along high productivity. I am quite aware of its strength and weakness.

But what could be wrong with his Rails implementation that could be that slow, assuming they are reasonably competent - a valid assumption I think given their successful port to node?

We all know that scaling up Rails is doable though not an easy task. To handle webscale traffic like LinkedIn in Rails, you can not go very far following the traditional ActiveRecord way. Very likely, you will introduce a high performance middleware to prepare the data for rendering say in Java/C/C#. For the frontend, you have jQuery or whatever Javascript library you like. You just leave Rails to handle routings. Though some people may challenge that if it is necessary to have Rails in this architecture. I think Rails can still make a case even in such scenarios, which is basically what github does.

I think you answered the question. You scale Rails by slowly replacing it. The problem with their architecture is that they hadn't done that yet. Node is handling their web scale traffic as-is.

Maybe I didn't make myself clear. My point was that their Rails implementation may not be well written, i.e., not architect-ed properly since beginning. You cannot simply throw a few tables and scaffolds and hope it scale. That way may work for small apps, definitely not for web-scale apps like this.

To be fair, Node.js also has its own quirks, besides the callback maintenance issues, I also mentioned in another post that Node.js is not as scalable as a lot of people present it to be.

Comparing rails and nodejs isn't really a fair fight. Rails has a ton of shiny bits that bare node simply doesn't. Comparing the two on speed alone isn't going to be overly productive.

Reply on news.ycombinator.com