How to speed up Ruby on Rails applications

I'm the sole developer of Taaalk. A Ruby on Rails application running on the Rails edge branch. Taaalk was built without considering performance and slowed to a crawl when under high load. The source code of Taaalk can be found here: https://github.com/joshinlisbon/taaalk_edge
I am a Senior Software Engineer at BigBinary.

I have been working on Ruby, Ruby on Rails for almost 7 years now. I have worked on and lead numerous projects on Rails and React. I have been involved with different stages of the project starting from prototyping to optimizing slow monoliths.

I have written several blogs on Ruby, Ruby on Rails, and Browser Extension Development as well at https://blog.bigbinary.com/authors/amit/.
Follow this Taaalk

5 followers

712 views

Joshua Summers
15:57, 29 Jan 21 (edit: 16:01, 29 Jan 21)
Hello Amit ūüĎč and thank you for Taaalking with me
You are talking to someone who loves Ruby on Rails, but knows nothing about how to make it performant.
Before we dig into any coded examples, I thought it would be good to explore the topic at a high level to understand how you think about it. 
So, do you have a philosophy on Ruby on Rails performance? For example, core ideas that you think every application should stick to and an idea in your mind of their order of importance... or perhaps it does not work that way!
Amit Choudhary
14:32, 03 Feb 21
Hey Joshua
Thanks for inviting me to this. About Ruby on Rails performance, I don't agree with quite a few people who are of the view that Rails is slow and not scalable. I have been working on Rails for almost 7 years now and have worked on quite a few applications which even after 3 years of development weren't slow. At the same time, I have also worked on applications that were slow just after 6 months of development because of enormous n+1 queries, the bad structure of views, and loading too many things on a single page.
I have also seen NodeJS applications that were on a slower side because of the bad DB structure. 
Rails recommends quite a few ways to keep the application fast. If we are following them, we should have a decent performant application most of the time. But if an application is slow and is hard to use, there are quite a few ways to identify the problem and then apply the solution. Fixing n+1 queries, fixing the database structure, optimizing views, adding caching, and using turbolinks are a few of the solutions,
Joshua Summers
16:35, 05 Feb 21
Got it.
And for you, do you feel like the order you gave:
Fixing n+1 queries, fixing the database structure, optimizing views, adding caching, and using turbolinks are a few of the solutions
Is typically the best pathway to go about solving things?
For example, if you were given a project 'blind' and you had to improve performance as quickly as possible, would you try to solve those issues one by one as listed above?
Amit Choudhary
17:35, 05 Feb 21
In most cases, yes but it depends on the findings too. Let's suppose that we check an endpoint and we see that 80-90% of time consumption is because of the views, then it makes sense to do the views optimization first because it's critical here. If we fix the views, it's gonna really speed up the application and then we can go back to fixing other things. If another endpoint is slow because of the database time consumption, there it makes more sense to look into n+1 queries and the database structure.
Joshua Summers
18:01, 05 Feb 21
Right, so it sounds like checking an endpoint is a way to diagnose performance issues on Rails.
Would you mind telling me about how you go about doing that?
Amit Choudhary
18:07, 05 Feb 21
When you load a page, the default logs will give you an idea about it. It will look something like this in the local environment as the last line for endpoint logs.
Completed 200 OK in 2607ms (Views: 2581.8ms | ActiveRecord: 4.3ms | Allocations: 3352499).
You can also use app performance monitoring tools like Newrelic to fetch more information and suggestions.
Also, https://github.com/MiniProfiler/rack-mini-profiler is an excellent gem to get some idea about where to make improvements.
Joshua Summers
18:14, 05 Feb 21
Right, I got it. I hadn't looked at the logs too closely to see they offered that kind of detail. 
How much does 'load' impact performance when it comes to using the clues given when checking an endpoint to make improvements?
For example, my site might be laser fast on my localhost, but slow down when facing a spike in traffic. Would the logs be a useful method of diagnosis then? (Or would checking for server logs be the thing to do...?)
Amit Choudhary
18:20, 05 Feb 21
In that scenario, I would check the server logs, database pool usage, memory/cpu usage etc. at the time of spike or at the time when the application is on a slower side. I would suggest adding a constant monitoring tool like Newrelic for better insights.
Joshua Summers
18:37, 05 Feb 21
Right. And is there any intuition that can be gained from when a site is running badly at a high load but fast when there is little demand for it. For example, are views consistently slow? But n+1 queries 'add up' under high levels of load? Or are these things independent of load?
Follow this Taaalk

5 followers

712 views

Start your own Taaalk, leave your details or meet someone to Taaalk with.