Ruby on Rails Scalability

[CubanCorona]

I've heard a good amount about issues with the scalability of websites implemented on Rails.

As I understand it, a lot of the scalability problems can be avoided by taking a "shared nothing" approach, which makes intuitive sense.

Does anyone have any good input on this? In particular, what common Ruby operations or website features would conventionally be implemented using application shared data that would violate the "shared nothing" approach?

 

[Crusty]

I wish I could give you a better answer, but I've just started working with RoR(last week). If you follow the standard rails RESTful design I don't see how Ruby and more specifically Rails would be causing such scaling issues. Unless my understanding of a shared nothing architecture is wrong I think that scaling issues relies more on application design rather then the design of Rails.

 

[trexpesto]

Just happened across this article concerning some criticism on the Ruby framework scalability.

 

[CubanCorona]

Thanks guys. Crusty--that's what I was thinking as well, which is why I was curious what sites like Twitter that are having scaling issues have done differently.

Thanks for the link, trex.

 

[hooflung]

There really not a problem scaling the RoR infrastructure if you build your tech from the ground up to support it. First you move your static images to be served from Lighttpd either on the same machine and use reverse proxy to pump requests of your RoR site to a Mongrel Cluster. Or you set up a light web box that only does static image serving.

Once you have a mongrel cluster you can set up multiple mongrel servers that will span and fill up your machine as needed. You can even move more clusters to more machines if you need them. You could even use JRuby to drive it all so you get the benefits of Java's memory management and threading.

That article is pretty dumbfounded to be quite sure. Sounds to me like all he really needed was Code Igniter and he's trying to cop out saying RoR is too big for its own good. Different tools for different jobs.

 

[serox]

Originally posted by: hooflung
There really not a problem scaling the RoR infrastructure if you build your tech from the ground up to support it. First you move your static images to be served from Lighttpd either on the same machine and use reverse proxy to pump requests of your RoR site to a Mongrel Cluster. Or you set up a light web box that only does static image serving.

Once you have a mongrel cluster you can set up multiple mongrel servers that will span and fill up your machine as needed. You can even move more clusters to more machines if you need them. You could even use JRuby to drive it all so you get the benefits of Java's memory management and threading.

That article is pretty dumbfounded to be quite sure. Sounds to me like all he really needed was Code Igniter and he's trying to cop out saying RoR is too big for its own good. Different tools for different jobs.

Just wanted to say that this post is all based on public postings from Twitter and DHH. Also the threading issue has been a big one for the most part. Sure you can throw mongrel's at the problem, but when something else scales much nicer and at a lower cost it is no surprise. Another rails article has been posted: http://www.resourcefulidiot.co...pts-but-not-much-else/

 

[Crusty]

So what does Twitter expect, someone else to hand them code that will magically make their application scale well? Now maybe they have some specific issues or major design flaws they have found, but NEITHER of those two articles mentions anything specific other then a 'threading issue'. From what I can tell the biggest drawback to Rails and more specifically Mongrel is that the more Mongrel instances you are running the more database queries you are running so it's not entirely easy to just throw a huge Mongrel cluster at the application and expect it to scale.

Not only does the Rails team tell users things are impossible, they even go as far to say that Twitter should do more to help. What honestly can they do? Twitter did not develop the framework, 37signals did. They are the ones that are posting the framework for public use and they should be the ones to tailor it to the broad applications that it is being used in.

LOL, RoR is totally FREE. End of story.

Twitter is the largest site to use RoR and the first to really take RoR to it's limits. Did anyone expect RoR to have all issues worked out before thrown at something this HUGE? I certainly wouldn't expect so, especially when it's seen such a small share real world applications compared to the amount php is used.

 

[George P Burdell]

Putting the language/framework aside for a minute, there are other issues that need planning on a scalable app:

1. Static content: Lighttpd is better than apache for static content (popular users include youtube and wikipedia). Another alternative to consider is Amazon S3, which takes the trouble of planning for scalable architecture out of your hands.

2. Caching: Caching is key to online survival. Cache database queries, session data, generated pages and whatever else you can. Applications like memcached are a good way to share a cache amongst several servers. The good thing about memcached is that it uses a lot of RAM with little CPU, while a webserver uses a lot of CPU with little RAM. It's like the two were made for each other.