Latest Business Blog Entries
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 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 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!
Proud owner of a Señor Developer t-shirt. Thanks a lot to the guys from
Señor Developer.
If you wanna get one of those as well, visit their
Shop.
Taken with
Instagram
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
If you just want to know, who of the people you follow on
GitHub
started watching
a repository, or
started following
anyone, simply setup a task on
ifttt
and don't get all the noise provided by the GitHub activity feed.
How to set it up
1. Create a new task
2. Click on
this
and select the feed symbol
3. Then choose the trigger
New feed item matches
4. Complete the trigger fields by entering
started watching
and your activity feed url
https://github.com/alto.private.atom?token=...
5. Create the trigger by pressing the button and select a target by clicking the
that
link.
6. Click on the email icon for example
7. Then choose the trigger action again
Send me an email
8. And finally create the new action by pressing
9. Give your new task a nice description and create the task
Finished!
If you wanna know what I'm doing next, the answer is quite simple. Me and
my family are going down under for a while, at least one year, to Wellington,
New Zealand.
I will work for a small company named
Sharesight,
who make share portfolio management really easy. My responsibility will
be that of a senior Rails developer.
I'm really looking forward to this adventure!
More details to follow.
I just started a new project, and it’s called makemates! I’m not yet telling what it’s all about, so stay tuned, and follow @makemates on Twitter while waiting.
It’s done, finally. Inspired by Jan Krutisch, and after having heard so much about Jekyll, I rewrote my homepage (and yes, once again, a little redesign).
The image I used for the header background was taken by myself using Instagram.
We made it! The Awesome Fontstacks are the Most Useful web application, which has been built during the Rails Rumble 2010 (here’s the final result). Thanks to everyone who voted for us! Thanks a lot to the best team of the world. And very special thanks to the man who had the idea, Wolfgang Wopperer!
Dieses Jahr habe ich endlich am Rails Rumble teilgenommen. Und zusammen mit Wolfgang Wopperer, Jan Krutisch und Florian Munz habe ich die Awesome Fontstacks gebaut, mit dessen Hilfe man sich eigene Fontstacks für seine Webseite zusammenstellen kann. Selbst wenn man - wie ich - so gut wie keine Ahnung von Typographie hat!
Es war wieder mal soweit, ich konnte mein bisheriges Layout nicht mehr sehen. Also habe ich ein komplett neues entworfen und dabei auch gleich die HTML-Struktur überarbeitet. Außerdem habe ich ein paar HTML5- und CSS3-Elemente verwendet, sollte aber trotzdem und immer noch im IE funktionieren…
Older Posts are to be found in the archives...
