Do Son 
Image Source: Pexels
Sooner or later, your large Rails application will run into performance issues that reside in the endpoint. It’s in your best interest to fix performance problems before your code becomes production-ready, but you can still troubleshoot a slow Rails product by doing the following.
Common Rail Performance Culprits
Rail performance isn’t too difficult to troubleshoot. 90% of the time, you likely have an N+1 query or missing foreign_keys on your database. Here are some other reasons why Rails is tanking:
- N+1 query and/or missing foreign_keys on the database.
- No Memoization or cache is used within your code.
- Network access issues (heavy API calls to external sites).
- Lack of tasks running in the background.
- Choosing to debug or conduct performance audits manually.
Even the best coders can’t conduct routine maintenance on large Rails applications without tools. Use Ruby on Rails performance tools, like Scout APM, so you know immediately when a performance issue occurs in between manual audits.
How to Diagnose Common Performance Issues in Rails
Relying on tools will make you a more efficient programmer, but it won’t necessarily help you understand why these problems occurred in the first place or how to improve your coder.
N+1 Queries
Start with N+1 queries first because it’s the most likely culprit. Thankfully, it’s also the easiest to fix. To find N+1 queries in your code, look for multiple queries with the same data that differ by id. You’ll typically find an “= 2” or another larger number than 1 at the end of the query.
To solve this, add an IN (#, #, #) instead of a “= #” for each number of users in your queries. For example, IN (1, 2, 3). Doing this will ensure Rails completes the same function once instead of multiple times for each user. Alternatively, you can upgrade to Rails 6.1 for “strict loading” mode.
Gems are an easy solution for eliminating N+1 queries if you have thousands of records. Simply add gem ‘bullet’ to optimize any query in any group as long as you enable Bullet configuration.
SQL Queries
If N+1 queries aren’t the problem, you may have missing indices or a poor SQL scan strategy.
Any query performing any selection (WHERE / HAVING) or ordering usually has to be indexed. Although Rails 5 automatically indexes foreign keys if you use reference words, some ids are left out. Adding a subquery is likely to fix this issue because it gives the code a head start.
If you’re indexing tables, Ruby may use the most inefficient way to understand its data. To see if this is the case, run an EXPLAIN ANALYZE statement in your database (not rails) console and use a tool to understand where the high/low numbers exist in the plan. Then, you can optimize.
Tables with large numbers may execute a sequential scan, making the database go through every row to find a matching condition. If this is happening, you’re missing an index.
Other Queries
The following queries aren’t as common but could show up depending on how often you tweak your code. Optimizing your SQL queries should work, but if it doesn’t, consider improving:
- Missing Cache: Caching improves Rails response time, and luckily there’s a lot you can take advantage of here. Rails.cache.read/write/fetch is a common low-level caching, but HTTP, page, action, and fragment caching are also helpful for speeding up your code.
- Memoization: Another caching technique, Memorization stores a computed value to avoid duplicate work. Memorization uses # GOOD/BAD and current_account access.
- Missing Background Jobs: A simple but often overlooked error, you can separate a one-step process into multiple steps to avoid Rails lagging when completing a job.
Remember to always conduct an automatic and manual diagnostic for Ruby on Rails performance issues because some problems may not be found or fixed by tools or software.