Dream of the kind of world
you wanna live in.
Dream it out loud,
at high volume

Bono, U2

Blog

08 May 2012 Benchmarking Rails 3

tl;dr

While Rails having become faster from version 3.0 to 3.2 regarding most parts of it, it actually became much slower when simply reading from the database.

Details

A couple of days weeks ago, when starting to switch over to Rails 3.1 from Rails 3.0, our project Sharesight got slower and we simply couldn't find out what the reason was. Especially where my own experience with Rails 3.1 was a good one, and most projects were at least a little bit faster than running with Rails 3.0 . But not this time. We finally decided to start creating new blank Rails apps, benchmark certain things and compare the results. And here we are now.

We created the GitHub repository Simple Benchmark and could reuse some of TST Media's groundwork, so we didn't start from scratch. The project consists of three Rails apps, one based on Rails 3.0.12, one on 3.1.4, and finally one on 3.2.3, the most recent stable one. We provided some tests with certain scenarios, which we think are the most interesting: reading from and writing to the database, and processing a couple of get requests (without database access). We wrapped it all up in some benchmark reports, resulting in two charts.

The first chart shows four lines: reading from the database (blue line), writing to the database, writing with some life-cycle hooks turned on, and finally writing with some validations turned on. First surprise was that running validations (green line) took much longer, but maybe it's because of the regular expression we were using.

Chart displaying the benchmark results for reading and writing the database

Chart 1: Accessing the database

But there's one more thing which actually comes as a surprise. All write requests got slightly faster while moving up the Rails versions. But reading from the database got slower. And it's actually much slower, it's more than 40% slower if you switch from Rails 3.0 to Rails 3.2! This means that displaying content from the database got more expensive, while writing to it was improved, which is a major point for most websites, I guess.

As you can see in the second chart, times improved from Rails 3.0 to 3.2, though being even better in Rails 3.1. Rendering with partials (the yellow line) took - as expected - the longest time to process.

Chart displaying the benchmark results for rendering pages using Rails

Chart 2: Rendering

So, what does this all mean?

For websites heavily reading from the database this is a major impact, since a surcharge of 40% is quite a change to the worse. So if you have a lot of database selects per request (actually hitting the database, not coming from any cache), you better start off optimising your site before switching over to Rails 3.1 or 3.2 . We had an impact of around +25% on our heaviest request, so we started optimising the processing time now.

Feel free to take a look at the benchmarking setup we chose. Any comment is appreciated!

separator line separator line

17 Apr 2012 Five Factors to make your Life more creative

Space: “You can’t become playful, and therefore creative, if you’re under your usual pressures.”

Time: “It’s not enough to create space; you have to create your space for a specific period of time.”

Time again: “Giving your mind as long as possible to come up with something original,” and learning to tolerate the discomfort of pondering time and indecision.

Confidence: “Nothing will stop you being creative so effectively as the fear of making a mistake.”

Humor: “The main evolutionary significance of humor is that it gets us from the closed mode to the open mode quicker than anything else.”

John Cleese, A lecture on creativity, 1991

separator line

16 Apr 2012 Vulcano

Instagram Photo of Mount Ruhapeha, Wellington, New Zealand

This is Mount Ngauruhoe in the Tongariro National Park, New Zealand, most likely known as Mount Doom of Mordor from the Lord of the Rings trilogy. And yes, we did the Tongariro Alpine Crossing, together with our little 5 year old kiddo Kester, who walked the whole distance of 19.4 km!

Taken with Instagram

separator line separator line separator line separator line separator line

12 Mar 2012 Calculate until saved

Let's say you have an attribute of an ActiveRecord object which is somehow calculated based on the state of the object, and let's assume this calculation is really expensive in terms of performance. Then calculate_until_saved might be for you:

Here's the module which you can easily store under lib/calculate_until_saved.rb

separator line

11 Mar 2012 Yeah!

Instagram Photo of a Yeah! event in Wellington, New Zealand

That's one of the reasons why I am in New Zealand...

Taken with Instagram

separator line

Older Posts are to be found in the archives...