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?
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.
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 to have an idea of how performance is going to be like on Rails 5.
undefined method `xhr' for #<RSpec::ExampleGroups::AdminDashboardController::WhileLoggedInAsAnAdmin::Index::VersionCheckingIsDisabled:0x00564a2c54c820>
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
Note that we actually override the default ActiveRecord#pluck and use our own implementation of fast_pluck. 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.
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:
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.
Make sure our https://rubybench.org/ reflects this loss in performance so we can (cough) encourage people to take action on this.
The categories page, and other key pages, should be at roughly the same speed as Rails 4, within 5%.
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.
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.
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
and the following is the correct benchmark for our topics page:
# 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
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 so that I can use those metrics to work with the Rails team and get us back up to speed.
@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.
Not quite.. Iām going to use the results Iām getting from profiling with 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?
Will grind through those next week!
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!
