When you load up Scout APM, you'll see a graph of recent requests. They are segmented by the different parts of your application e.g. Middleware, ActiveRecord, Ruby, and Request Queuing.
You can drill down into slow requests only by clicking "What's Slow" at the top or by dragging your mouse across the graph to select requests and clicking "See 4 slow requests" if applicable.
It should be fairly easy to predict which endpoints might be making too many database calls. Pick one and load it up.
On the next page, you get a nice breakdown of this endpoint based on the requests from the time period chosen. You can also select individual requests on the left for more detail.
The important part I want to direct your attention to is the orange N+1 icon. This means that within my 'home/index' controller, I'm making 500 calls to User#find (User.find or similar) and its taking an average of 1,367.9 ms.
Clicking the 'SQL' button will show you the problem query.
In my case, it's
SELECT `users`.* FROM `users` WHERE `users`.`id` = ? LIMIT 1
This means I'm querying for users inside of a loop.
If you are using Scout's Github integration, you can see down to the line of code where the query is originating from. Click the 'CODE' icon to get this UI.
Fixing an N+1 call is fairly simple with Rails. You need to employ the help of something called "eager loading". Eager loading allows you to specify in advance which associated models you plan on using. Do this using the "includes" method of Model.
@meals = Meal.where(visibility: 1).limit(500)
@meals = Meal.includes(:user).where("visibility = 1").limit(500)
You do not need to change the way you're accessing the data later in your views. Rails takes care of that for you.
Test these changes locally and run your unit tests. After deploying, check Scout APM to make sure you've eliminated the N+1 queries.