Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not sure I understand how to integrate what you are saying with what I read in the post. If RoR is dog-slow--let's pick 100x slower than something you would code in the weekend--but scales, then what they can serve with 100 servers = what you serve with one server. To double capacity, you add one server and they go from 100 to 200. And so it goes.

Scalability is a second-order issue: if you go from 1 server to 2, but they need to go from 100 servers to 400 servers to handle the same load, then not only are they slower than you are, but they can't scale as well as you can.

I get why using a framework for the UI and business logic could make them 100x slower than something custom-coded. And from the original post, I get why a conventional database+read cache may not be appropriate for a messaging application.

But what I don't get is the connection between RoR and scalability. Unless you are speaking of its default configuration, namely RoR+ActiveRecord+MySQL. Which speaks more to the architecture choice (tables, rows) than to the framework choice (views, models, controllers).

or am I missing something?????



There is no connection. The fact that they're using RoR to build what is really a very, very simple web site suggests their problem is not knowing which tools to use, which is a problem you can not solve by throwing more hardware at it. Talk about scalability is a red herring in this case. The real issues are elsewhere.


Ah, so it's a case of "I believe their choice of Tool A is wrong for solving Problem B, thus although I cannot see what they have done with Architecture C to solve Problem D, I don't have a lot of confidence they made the right decisions."

Thanks for explaining your reasoning.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: