Having developed with Rails for a little bit now I have been eager to find out whether Rails in its current 2+ form will actually scale after having heard so much bad press from different areas. I thought that it might be interesting to jot down in one place my findings. One thing that I would like to say first though is that I am not a great believer in reinventing the wheel. I find that I lot of things that already work fine are being “railsified” just for the sake of it, rather than for any particular reason.

1. Speed and Scalability

Firstly Ruby is slower than some of the other popular languages. A fact not entirely missing in the world, but as most things it is being worked on as we speak. I remember not to long ago people bitching about the speed of Java, but over the many years it’s been out it has managed to get faster with each new version. A very good article is “On Ruby on Rails Criticism” is a very good article and should be read. He has a very good discussion based on how communities should embrace honest criticism, allowing them to focus on what should be corrected. He correctly states that Ruby is slower than python etc, but at no point does he say that it is slow. Being slower than the others doesn’t necessarily make it “slow” but you should consider this when working out what to use for your app. I find the following paragraphs sum up his article quite well.

“Sometimes the accusations towards Ruby or Rails are just ridiculous and are factually inaccurate. It is important that as a community we debunk these myths and unjustified criticisms. But it’s just as wrong to react with denial towards genuine criticism. For example if a blog states for the nth time that the Ruby interpreter is slow, there is no point in saying that’s not true, and that the benchmarks on the language shootout are bogus. Sure they may be considered worthless or not too representative of real world performance by some, but let’s be honest, we know that Ruby is slower than many other languages, why deny it? I’ve no problem with recognizing that Haskell is much faster than Python and that Python is faster than Ruby in most scenarios. There is nothing to hide or get upset about; Ruby is a wonderfully designed language whose main implementation is currently suboptimal.

Generally speaking, Ruby’s shortcomings aren’t sufficient enough grounds to discredit the language as a whole. Pointing this out in an argument is a better strategy than denying the problem a priori. As a matter of fact, I find Ruby to be fast enough for most tasks (on modern architectures), while still recognizing that an equivalent program in C would most likely be much faster. An even better road to take would be to provide examples of how computationally complex problems can be dealt with efficiently in Ruby, highlighting the best practices and the existing workarounds to deal with Ruby’s current weaker points.”

Penny arcade is a popular site mentioned that does use rails and considering that it is pretty much a customized blog it can cache most things easily, and can probably be run from one server quite easily. One thing that I like is that they don’t re-invent the wheel by trying to “railsify” everything else such as the forums. He uses the trusted and proven vBulletin which is more than capable for the job. A forum, like a blog is something that can be cached quite a lot as well so I doubt would run into many scaling problems.

I have read in many places that Twitter did have problems scaling with their growth, but considering how quickly they grew I could not have imagined it being different for any other platform. The biggest problem facing any large web application is scaling. Take a look at highscalability.com which contains a lot of information about scaling and the issues that have plagued the large sites. To be honest, when talking to anyone about scaling on any platform the first thing they will say is “throw more computers at it”. Its the basic answer to the ultimate question. High scalability has recently done a twitter architecture overview and an interview with Blaine Cook (Twitters lead architect- NB not anymore) and its definitely worth reading as its more up-to-date than most articles. It turns out that twitter do not blame rails in the least:

“For us, it’s really about scaling horizontally – to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster”? language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January.” – Blaine Cook. (17/01/2008)

(I would like to point out that Blaine has since left the company. Some have speculated that he was fired because of scaling problems that he was brought in to fix and others say it wasn’t. Twitter do not actually say anything anywhere to whether they sacked him or not so I will assume for now that he left of his own accord.)

Blaine also has a presentation on Google video entitled “Rails Scales” and is worth watching for those that have decided to use it as their web framework. One thing that the original article did not mention though is that twitter ran off one database. No wonder they were worried about more connections from the cluster instances . They do still run off of one database (a beastly 8 core server though) so kudos to them for being able to pull that off. From reading the overview you get that these people were inexperienced (like most of us when it comes to scaling) as twitter had originally been a hobby project that went crazy in a matter of months, also compounded by using Rails which was (and suppose still is) a relatively unproven framework compared to Java or even PHP apps. Their problems were basically down to in-expectant traffic and inexperience of scaling systems. The truth is when you read about all the big companies they all suffered major downtime due to scalability issues. A good book to read is “Founders at Work” – 1590597141. It contains interviews with the founders from Paypal, Hotmail, Excite, Yahoo, Blogger.com, Gmail, del.icio.us, craigslist, Flickr and many more. Every single one say that their biggest problem was scaling and lack of experience with how to deal with it. It is a good read and I would recommend it, as it was recommended to me (thanks Ian). So basically there is no magic formula to scaling any kind of technology. You just have to think smart and learn from those that have suffered in the past.

2. The Rails Community.

An open source project does need a good community to keep it going and I believe that there are very good people on board making it better and better. At the same time there are probably loads of people in the community (like many others) who are a little stupid and get things wrong – whether it be in articles, comments or quite a lot of smugness. Yes the rails in abundantly smug for some reason that I have yet to find out about. At the moment Rails seems to be the new cool thing so that means that all the followers are going to attach themselves to it, its happended to almost all the other technologies I can think of. There was a heap of smugness about using Perl, Python and PHP but after a while something new comes out and they move onto something else. It has nothing to do with the project and everything to do with the person. Also hype tends to surround things with a little merit. Whether you like Apple or not, they do make some cool things, whether you like rails/ruby or not it does have some cool features and the same can be said for a lot of things.

Ruby does try to keep you to a standard convention which should lead to good design. If you adhere to this way of coding, such as naming tables, models and controllers a lot of the glue will be done for you. The truth is that the methods for this are totally definable by yourself. In my application I do not need the rails glue for some things so I map it together myself. But be under no illusion, rails is very configurable its just that it is good to stick to best practices which can make your life easier. Anyone that has read a good book on rails or the API would know that it is very configurable for the times when you need to bend the rules. I was originally going to use a Java framework for my project, mainly because it is what I know best. But after spending a few weeks with them rails just seemed like a breath of fresh air. I can also honestly say that the same “breath” could have also been gained from using PHP or Python etc. I always found this picture of a j2ee stack trace to be very funny (I found it whilst reading this mongrel article on background workers). I absolutely love Java and always will. In fact I love it so much I have been writing my own Java framework (in my little spare time) and have been basing it on the things that I like in Rails and PHP.

3. Poor Documentation.

Now compared to say Java there is no where near as much documentation, but then again Java has loads more stuff. From what I understand documentation was lacking in the earlier versions, but from Rails version 1.2.4 I found it to be very good and now even better with the release of Rails 2.0. I can honestly say that I have managed to find everything I have needed when looking at the api docs so I cant argue with that.

4. Technical limitations with XML SQL..

I would take a guess that there might be problems with the standard Ruby libraries such as XML, but then again Java’s implementation was not very good for years (could still be for all I know) and the third party libraries were always the best. That’s why Rails uses another library for XML instead of the standard ruby one. JSON, XML and YAML are all provided in rails models with the ability to create custom ones using the builders (which will 99% of the time). For an easy example I could do the following to return an object as a JSON string to some javascript:

This will convert the person object to a JSON string. The same also exists for XML and YAML. Very useful for applications that are AJAX/JSON’y. One thing that I know for sure is that there will always be problems with standard libraries and that is not going to change in a hurry. What you do is fix it when you find any. Its like any language really, if you are not happy with the standard implementation then write your own. You are able to do this in Ruby like any other language.

I read a post on Google discussion and one thing immediately stuck in my face as being total crap:

“This means the important, actually hard stuff like handling the stateless nature of HTTP, or sanitising and escaping the user input is just not adressed at all, and you only learn about them when one day you discover 84 possible XSS injection points (actual number from a Rails app I’m somewhat famililar with).”

Rails has great session management and provides you with multiple options. You can choose from cookie, in memory and database management (as well as some third party modules I believe). And its all done with one line in the config. A rake task will even create the correct tables for you so that its all ready to go. Actually it creates a nice database migration for you so that you are able to revert back changes. Just a little feature that most frameworks do not provide as standard and is very useful.

This guy must not know much about Rails. The main design point with rails is the fact that a model handles all actions relating to that data set, such as any interaction methods and, lets wait for it… Sanitizing user input. It not only provides a set of validation helpers (of which you can write your own custom ones) but also provides a set of hooks for you to write you own methods for testing more complex items. The methods provided include validate, validate_on_create and validate_on_update. There are so many validation points that you sometimes feel guilty for not using them. Just so you know what I am going on about, here is an example of a simple order model that I stole from Agile Web Development with Rails:

If you cant find a point in any of that to sanitize the user input then you seriously need to stop working in the IT industry. Most of the ideas were stolen from Hibernate and that is probably the best ORM library available. For a better look at what is going on it is worth watching this video by the creator of rails to see just how much validation you can do with rails. He only provides a simple example and it was with one of the original versions of rails, but it is interesting none the less for seeing its useful features.

Since when has XSS had anything directly to do with the framework? Ensuring that you do not fall prey to these kind of attacks is on the system designer not the framework. The framework can provide you with methods for checking but its up to you to still check the input. XSS occurs because of people placing unscrupulous code in the app and not the framework. One welcome feature in rails 2.0 is that its changed its TextHelper:sanitize method from a black list approach to a whitelist approach making it much easier to keep ahead of new exploits. Another neat feature in 2.0 is that they have now protected cookies from Cross Site Request Forgery so you can be sure that the request is coming from your own application. Again something which is not normally available as standard on any other framework.

5. Uncertain Future

There is without a doubt enough momentum that someone will always carry it on just like any other large open source project. Plus there are too many large systems running on it now so they have a vested interest in its survival. I remember reading this article on Derek Civers a while ago when I first considered using Rails and thinking “bloody hell that rails must be bad”. But after reading you realize that he went into it with the wrong intentions and I don’t think he ever thought why he was switching in the first place. It seemed to be another “railsify” moment. He mentions that they never really got to do much on it because as he quotes:

“To be fair to Jeremy’s mad skillz: many setbacks were because of tech emergencies that pulled our attention to other internal projects that were not the rewrite itself”

One of the things I find is that you will find many stories like this. Everyone that reads this blog is most likely to be a computer guy in some way or fashion and you all must know how many projects fail every year, using the most and least popular choice of languages in the largest and smallest companies in the world. But they seem to carry on regardless, and certainly wouldn’t be scared of one bad story. After all, one persons failure cannot be reflected upon the whole community. If someone completely messes up a Java project, does that mean that Java is rubbish? Of course not, but on the other hand if most people did then it certainly would be. As always it is down to the ability of the person who is coding. I am sure that an excellent programmer could make something good out of the worst language/framework in the world. As they say “don’t blame your tools”.

If you are going to use shared hosting to actually host your application then don’t bother with Rails at all. (Update: According to a comment I have received from Hongle Lai he says that DreamHost now has a very good shared host environment so you may want to look into this) Rails was never really designed for that intention and a lot of the time it shows. If you want to go down the shared hosting path I would recommend PHP as it is very good in this environment. I love PHP and think it started a revolution in the web space. There are so many open source projects in PHP it is unbelievable, and a lot of them are amazing like WordPress (this blog uses it). There are no J2EE shared hosts that I can think of and if there were I would not imagine them being particularly good (that’s putting it nicely) . I can’t actually think of many JSP shared hosts either thinking about it but that could be because I have never really looked. For the biggest choice of hosts at the best prices I would personally consider PHP as the best option (as I have for this website).

6. Summary

Basically you have to realize that Rails and Ruby are far from perfect, but then so are all the other solutions I have looked at. No one out there has got the perfect solution and probably never will do. My reasons for choosing rails at the time was the ability to quickly create an application that would take me for ever using something else with the ability to really express my thinking semantically. I like the features in Rails as they just seem to make sense the more that you use it, and I really like that. I may have to get an extra server or two in the future, but honestly couldn’t care less. After you have completely maxed out the obvious options for scaling on the same hardware like caching, virtual servers etc and there is no more juice to squeeze out of a server the only option is to add more machines, but at least rails is ready for clustering from the start (well at least mongrel is) which can make your life that little bit easier later on. Well that’s as long as you thought about session management from the beginning.

My advice for anyone is to pull your sleeves up and get your hands dirty and find out for yourself. If you don’t like it, then fair enough – at least you have reason. Most of the time it makes sense for people to stick to what they know best if that is an option, because trust me, it is a steep learning curve getting to where you were with the other language. Just remember that old chestnut that “one mans meat is another mans poison”.

Thank you for reading.