# When should Discourse upgrade to Rails 5?
**URL:** https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123
**Category:** Development
**Created:** [July 30, 2017, 9:26pm UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123 "2017-07-30T21:26:52Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@gdpelican](https://meta.discourse.org/u/gdpelican)
#### Post date: [July 30, 2017, 9:26pm UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/1 "2017-07-30T21:26:52Z")
Hey Discourse Team,
This marks the 1-year-and-1-month anniversary of the Rails 5 release, it looks like 5.1.3 will be out soon (second release candidate lands today). Wondering if there have been any thoughts on upgrading Discourse to Rails 5.x anytime soon? Why or why not?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [July 31, 2017, 5:46am UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/2 "2017-07-31T05:46:30Z")
I think our main problem is that Active Record gets slower in each release? Not sure, but we worry much more about “keeping up with the Joneses” for Ember (client side JS) releases than Rails on the server side, which is quite mature.
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [July 31, 2017, 6:46am UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/3 "2017-07-31T06:46:42Z")
> [@gdpelican](#):
>
> Wondering if there have been any thoughts on upgrading Discourse to Rails 5.x anytime soon? Why or why not?
It is on my list to get us to the latest Rails but it isn’t our priority at the moment because none of the new features are useful for us. Right now, we’re working with a GSOC student to get our Rails benchmarks back in order on [https://rubybench.org](https://rubybench.org) to have an idea of how performance is going to be like on Rails 5.
---
### Author:  [@kajatiger](https://meta.discourse.org/u/kajatiger)
#### Post date: [August 4, 2017, 2:02pm UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/4 "2017-08-04T14:02:43Z")
I think upgrading to Rails 5 would be a good idea since the Action Cable could be useful especially for getting notifications…
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [August 4, 2017, 2:30pm UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/5 "2017-08-04T14:30:23Z")
We already use a much better library to handle all the notifications/updates 😉
[https://github.com/samsaffron/message\_bus](https://github.com/samsaffron/message_bus)
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [August 11, 2017, 3:30pm UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/6 "2017-08-11T15:30:18Z")
> [@tgxworld](#):
>
> because none of the new features are useful for us
This has kind of changed because of [Automatic encoding of parsed URL params - #26 by elijah](https://meta.discourse.org/t/automatic-encoding-of-parsed-url-params/67232/26) , if the upgrade is not to painful and there is no perf regression we should go ahead.
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [August 23, 2017, 3:32am UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/7 "2017-08-23T03:32:02Z")
I am in for a long long ride…
```plaintext
undefined method `xhr' for #
```
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [August 31, 2017, 9:19am UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/8 "2017-08-31T09:19:15Z")
Ok I have tests green going for the main code base in
[https://github.com/discourse/discourse/pull/5122](https://github.com/discourse/discourse/pull/5122)
When I thought I was done, I realized I’ll have to go through all our plugins as well otherwise 😿 Will grind through those next week!
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [September 5, 2017, 10:01am UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/9 "2017-09-05T10:01:36Z")
Rails 5.1 is now deployed on `meta`. I’m seeing performance regressed on the topics and categories page ATM so we can’t roll it out immediately to everyone. Another notable change is that Activerecord’s pluck is notably slower which I’ve submit a PR for in
[https://github.com/rails/rails/pull/30524](https://github.com/rails/rails/pull/30524)
_Note that we actually override the default `ActiveRecord#pluck` and use our own implementation of [fast\_pluck](https://github.com/discourse/discourse/blob/master/lib/freedom_patches/fast_pluck.rb). However, they code path being fixed here is shared between both implementation._
I’ll continue to profile the topics and categories page to see where the extra time is being spent on.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [September 5, 2017, 11:02am UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/10 "2017-09-05T11:02:52Z")
> [@tgxworld](#):
>
> I’m seeing performance regressed on the topics and categories page
Can you please specify how much, in percent?
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [September 6, 2017, 1:19am UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/11 "2017-09-06T01:19:19Z")
### 4.2.9
```plaintext
Your Results: (note for timings- percentile is first, duration is second in millisecs)
---
categories_admin:
50: 18
75: 18
90: 19
99: 27
home_admin:
50: 23
75: 23
90: 24
99: 29
topic_admin:
50: 18
75: 18
90: 19
99: 25
categories:
50: 43
75: 43
90: 48
99: 50
home:
50: 46
75: 48
90: 53
99: 71
topic:
50: 19
75: 20
90: 21
99: 26
```
### 5.1.3
```plaintext
Your Results: (note for timings- percentile is first, duration is second in millisecs)
---
categories_admin:
50: 21 # 16.6%
75: 21
90: 24
99: 32
home_admin:
50: 25 # 8.7% slower
75: 25
90: 26
99: 31
topic_admin:
50: 21 # 16.6% slower
75: 22
90: 23
99: 28
categories:
50: 44 # 2% slower
75: 46
90: 50
99: 73
home:
50: 48 # 4.3% slower
75: 53
90: 54
99: 80
topic:
50: 22 # 15.7% slower
75: 23
90: 25
99: 32
```
I ran the bench again this morning and included the results and regression in percentage below.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [September 6, 2017, 1:20am UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/12 "2017-09-06T01:20:31Z")
Topic is an absolute showstopper, that is a core page. Categories can be too, if it is the homepage.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [September 6, 2017, 9:36pm UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/13 "2017-09-06T21:36:59Z")
OK @tgxworld says this is ActiveRecord getting slower and slower in each new version, such that even the simple / basic queries are contributing a lot to general slowdown ☹ In a particular kick in the pants, even our “fast pluck” @sam wrote got slower because it relied on parts of Rails internals that also got substantially slower!
Here are our priorities for the Rails 5 upgrade:
1. We need to bypass ActiveRecord since it keeps getting slower, **especially on the topic page**. This is the most important page in our application! Let’s target a **20% speed _improvement_ on the topic page** , by bypassing ActiveRecord and doing raw queries.
2. Make sure our [https://rubybench.org/](https://rubybench.org/) reflects this loss in performance so we can _(cough)_ encourage people to take action on this.
3. The categories page, and other key pages, should be at roughly the same speed as Rails 4, within 5%.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [September 7, 2017, 5:15pm UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/14 "2017-09-07T17:15:55Z")
> [@codinghorror](#):
>
> Make sure our [https://rubybench.org/](https://rubybench.org/) reflects this loss in performance so we can (cough) encourage people to take action on this.
We created this particular bench just for this particular case [https://rubybench.org/rails/rails/releases?result\_type=active\_record/postgres\_discourse](https://rubybench.org/rails/rails/releases?result_type=active_record/postgres_discourse)
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [September 7, 2017, 7:26pm UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/15 "2017-09-07T19:26:06Z")
> [@codinghorror](#):
>
> We need to bypass ActiveRecord since it keeps getting slower
That sounds true, but it also seems like a huge drag. I’m still (almost?) a Rails novice, but it seems like ActiveRecord is sort of the basis of the whole endeavor. And then writing around it will make things all the more fragile for future updates. Yuck.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [September 7, 2017, 11:25pm UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/16 "2017-09-07T23:25:58Z")
Unavoidable since the performance is dismal, if you ever care about performance. Also not quite true, it won’t be fragile – the database is the model, not the code.
These SQL-to-ORM things are always a mixed bag. You give up a _lot_ for what you get, and it’s almost a religious issue, like many things in programming. See [Object-Relational Mapping is the Vietnam of Computer Science](https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/)
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [September 8, 2017, 6:22am UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/17 "2017-09-08T06:22:28Z")
Some updates on this, it turns out that our profile script used an incorrect `topic_id` in the URL which means that we’ve been profiling against a private message page with one post instead of a public topics page with multiple posts. I’ve fixed it in
[https://github.com/discourse/discourse/commit/4142bed1af8cf6d5ca4accd2205d3f7ff5277398](https://github.com/discourse/discourse/commit/4142bed1af8cf6d5ca4accd2205d3f7ff5277398)
and the following is the correct benchmark for our topics page:
```plaintext
# Rails 4.2.9
Your Results: (note for timings- percentile is first, duration is second in millisecs)
---
topic:
50: 53
75: 54
90: 60
99: 76
timings:
load_rails: 1188
ruby-version: 2.4.1-p111
rss_kb: 186964
pss_kb: 123467
virtual: physical
architecture: amd64
operatingsystem: Ubuntu
memorysize: 15.59 GB
kernelversion: 4.10.0
physicalprocessorcount: 1
processor0: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
rss_kb_3476: 350996
pss_kb_3476: 285127
rss_kb_3557: 349488
pss_kb_3557: 284004
rss_kb_3792: 349364
pss_kb_3792: 283873
```
I noticed an inefficiency in our code base today and managed to recover performance with
[https://github.com/discourse/discourse/commit/5d4221fbe1cd2000ac10088c5ea8a8016eb64ad8](https://github.com/discourse/discourse/commit/5d4221fbe1cd2000ac10088c5ea8a8016eb64ad8)
About a 22% increase for the 50th percentile. Note that this isn’t Rails 5.1 related, just a performance regression that we’ve been carrying around for some time.
On the Rails 5 front, I’ve basically been adding more benchmarks to [RubyBench](https://rubybench.org/rails/rails/releases) so that I can use those metrics to work with the Rails team and get us back up to speed.
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [September 13, 2017, 3:46am UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/18 "2017-09-13T03:46:38Z")
I’ve just deployed `meta` back on Rails 5.1 after we reverted it thinking that it caused [Can't change "default locale" - #6 by tgxworld](https://meta.discourse.org/t/cant-change-default-locale/69384/6). Let me know if you notice any new bugs 🙂
> [@codinghorror](#):
>
> We need to bypass ActiveRecord since it keeps getting slower, especially on the topic page. This is the most important page in our application! Let’s target a 20% speed improvement on the topic page, by bypassing ActiveRecord and doing raw queries.
@codinghorror We’re not going to be able to bypass Active Record entirely and drop straight to raw SQL since we have alot of logic baked in to our serializers that we use to form the json payload. So for, I’ve skipped AR in favor of SQL on the topics code path whenever possible.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [September 13, 2017, 3:49am UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/19 "2017-09-13T03:49:09Z")
Did we meet our goal of 20% speed improvement on topics page and no regression in performance on categories?
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [September 13, 2017, 6:20am UTC](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123/20 "2017-09-13T06:20:47Z")
Not quite.. I’m going to use the results I’m getting from profiling with [ruby-prof](https://github.com/ruby-prof/ruby-prof) since the results I’m getting from our profiling script varies quite between each run and between each day I run the benchmarks. @sam I’m not sure if you noticed this previously?
#### 1. Master
100 requests took: 13.31 seconds
#### 2. Master with `PERF` commits applied
100 requests took: 12.61 seconds ~5.2% improvement compared to `1`
#### 3. 5.1.3 with `PERF` commits applied
100 requests took 13.54 seconds ~7.4% slower compared to `2`
#### 5.1.3 after recovering some performance from Rails
100 requests took 12.89 seconds ~2.2% slower compared to `2`
> [@codinghorror](#):
>
> no regression in performance on categories?
Not sure about this yet as I’ve only been profiling the topics page.
[Next page](https://meta.discourse.org/t/when-should-discourse-upgrade-to-rails-5/67123.md?page=2)