Why I love Ruby on Rails and what should be said on it's performance , part 1

In less than a week, you can establish a working model for your final product.

It is, however, very unwise to consider this is the end of the process.

Ruby on Rails allows ultra-fast development but all this comes in exchange to performance and efficiency.

At the end of the first development period you find yourself with a great working copy but with very low efficiency and as soon as your site starts growing you have to add more servers, more memory, more everything.

What can and should be done in this stage is the infamous 're-factoring' procedure with high attention on performance.

For example for Article and User where each user has many articles and each article
belongs to a user ( 1 -to- many relationship)

If we want to get an article's user email we railslishly write:

Article.find(123).user.email

Which feeds our logs with:

Article Load (0.002447) SELECT * FROM articles WHERE (articles.`id` = 123)
User Load (0.002856) SELECT * FROM users WHERE (users.`id` = 8)

This isn't a problem if you have a small application, this isn't a lot ah? 2 are 100% more SQL queries than only 1 query...

Actually, it's okay to live with it as long as you don't need to grow. When you do, you have to learn SQL.

The truth is even basic SQL can save you here (something PHP or ASP developers would never brag about...):

select * from articles inner join users on users.id = articles.user_id where articles.id = 123

Word is around that Ruby on Rails is slow because of Ruby. The truth for large scale websites is that Rails has much more to do with performance than Ruby.

Let's try a Tiny Profiling Utility on the the scenario described above, where in both cases I want to get an author email according according to it's ID:

>> prof(1000) { Article.find_by_sql('select * from articles inner join users on users.id = articles.user_id where articles.id = 123').first['email'] }
time: 0.004523629(s) . req/s: 221.061453094407
=> nil
>> prof(1000) { Article.find(123).user.email }
time: 0.005518112(s) . req/s: 181.221403262565
=> nil
>>

For one simple action we see a difference of around 20% in speed. Take into consideration that more time consumed by the SQL server is more time other queries are waiting in line, etc. etc.
Let's do the previous test for two articles (123 and 567):

>> prof(1000) {
a = Article.find_by_sql('select * from articles inner join users on users.id = articles.user_id where articles.id = 567 or articles.id = 123')
a[0]['email'] + a[1]['email']
}
time: 0.004959934(s) . req/s: 201.615586013846
=> nil
>> prof(1000) {
a = Article.find(567,123)
a[0].user.email + a[1].user.email
}
time: 0.008703669(s) . req/s: 114.894075130844=> nil

Now that's around 40% difference... imagine what would happen in the case of Many-to-Many connection...

The truth is that eager loading in Rails, should solver this issue - but for some reason it's slower... :
>> prof(1000) {
a = Article.find(567,123, :include => :user)
a[0].user.email+a[1].user.email
}
time: 0.006641206(s) . req/s: 150.575061216291
=> nil

Rails is a great framework and Ruby is a wonderful language, use them and learn some SQL too, they work much faster together...Start using it now: http://rubyonrails.com

Don't forget your sql... http://w3schools.com/sql/default.asp

enjoy!