# Speeding up Rails 4.2

DevFeed: [Speeding up Rails 4.2](<https://devfeed.tech/articles/speeding-up-rails-4-2-41336.md>)

Original publisher: [Read original article](<https://samsaffron.com/archive/2014/12/01/speeding-up-rails-4-2>)

Author: Sam Saffron

Published: 2014-12-01T04:30:19Z

Content type: article

Language: en

Sources: [Sam Saffron](<https://devfeed.tech/sources/sam-saffron.md>)

Topics: [Rails](<https://devfeed.tech/topics/rails.md>), [Benchmark](<https://devfeed.tech/topics/benchmark.md>), [Performance Testing](<https://devfeed.tech/topics/performance-testing.md>), [Ruby](<https://devfeed.tech/topics/ruby.md>)

Tags: [benchmark](<https://devfeed.tech/tags/benchmark.md>), [performance-testing](<https://devfeed.tech/tags/performance-testing.md>), [rails](<https://devfeed.tech/tags/rails.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

This article examines Rails 4.2 performance using the Discourse benchmark, a macrobenchmark that loads users and topics and measures performance with Apache Bench. Initial results showed Rails 4.2 running at about half the speed of the earlier setup, prompting efforts to identify and fix the regressions before release.

## Source excerpt

Recently Godfrey Chan got Discourse working on Rails Master. It was a rather long task that involved some changes to Discourse internals and some changes to Rails internals. Knowing Rails 4.2 was just around the corner I decided that it seemed like the perfect time to see how performance is. Seeing Rails 4.2 contains the adequate record patches, I was super eager to see how Discourse fared. ###The Discourse benchmark Answering the question of "how fast is Ruby?" or "how fast is Rails?" is something people usually answer with the following set of steps. Upgrade production to a certain version of Rails Look at New Relic reports Depending on how performance is either complain on Twitter and/or Blog or write a few kind words. The trouble is that performance testing after release is the absolute worst time. Code is in production, fixing stuff is tricky, rolling back often impractical. At Discourse I developed the Discourse benchmark. It is a simple script that loads up a few thousand users and topics and then proceeds to measure performance of various hot spots using apache bench. I have found that the results of the benchmark are strikingly similar to real-world performance we see. If the benchmark is faster, it is very likely that it will also be faster in production. We use this benchmark to test Ruby before major Ruby releases. Koichi used this benchmark to help optimise the current GC algorithms in MRI. It is often tempting to look at micro benchmarks when working on performance issues. Micro benchmarks are a great tool, but MUST be followed with bigger macro benchmarks to see the real impact. 1000% speedup for a routine that is called once a day in a background job has significantly less impact than 0.5% improvement to a routine that is called on every web request. ###How was Rails 4.2 Looking? For over a year now, Discourse had the ability to dual boot. This allowed me to quickly run a simple benchmark to see where we were at (arel , rails): % RAILS_MASTER=1 ruby