Skip to main content

Debugging Performance Problems In Your Views | GoRails - GoRails

General • Asked by Chris Oliver

Hi Chris, this issue is called N+1 problem and one of the ways to face it is by doing "eager loading" because sometimes you still need to use your step object in the view, so in the controller it's just simple as doing something like that : @steps = Step.all.includes(:course), you can even go deeper : I don't remember the syntax exactly but it's something like that steps.all.includes(course: [:other, :category, ....]), sometimes when you need more complex query you should use join instead of includes... I had the issue a long time ago when I wanted to implement an activity feed where every post has to bring the author and the comments for that post and also the users who write the comments...

Well, we actually eager load the sections, steps and privacy settings at the beginning through the course. That's all done and was the obvious thing to look at for performance, but the real bug here is more subtle in that we've loaded the object already but weren't referencing it correctly.

Those are all equally important in building performant responses though!

I watched the video again trying to understand... what I understand from you is that you already had @course in the controller but you didn't use until discovered the performance issue ! also you loaded sections, steps and privacy through the course. What I was saying is if you eager load the course through the step it will not produce that problem.

I might re-record it with a clearer example. It could be explained a lot better.

sorry that I was not be able to understand :( it may be clearer for me if I can see how the controller handle that, but you don't have to record the video again if I am the only one who don't understand, you can wait until seeing what others say! :)

No worries! I'm going to re-watch it tonight because I'll probably have the same feeling and get you a much cleaner example including the controller that I eluded to but never showed. Showing the controller will clear up a lot of things I think.

I was just going to give you a heads up: I re-recorded this episode and think it's a lot more clear this time. :) Thanks for your help because it definitely needed to be cleaned up!


This episode is more clear, I can see why you had that performance problem, your solution is the best in this case, but I think I know why step.course does trigger the database each time because I deal many times with eager loading in the past! let's imagine you only eager load "steps" like this @course.sections.includes(:steps) , in this case the requests are : 1- it fetch * from sections where the course_id equal @course.id then 2- it fetch * from steps for **each** section (but it doesn't fetch the course for each step, so just I may told you before, if you do steps: :product which I now it's redundant and inefficient because you already have @course then you will not have the performance problem); I don't know if my explanation is clear but in general : steps are loaded for each section, so: @course.sections.find(3).steps or even @course.sections.find(3).steps.find(5) will not trigger the database, but if you try to do the inverse and access @course from a step then obviously it will trigger the database. I hope I am not confusing this time!


Hey Chris! I'm really excited for the Rails from Scratch series. If you can include how gems are incorporated into a Rails app from outside of the project's folder, that would be awesome. Thanks for doing this!

Gems are definitely a topic I want to cover. There are a lot of little things related to that (like why do we have Bundler and how does it help?) so I'll make sure there's at least one episode on this gem related things.


Hey Chris,
What ever happened to that Rails from Scratch series? Not doing it again or is it postponed until a later date?

I'm still planning on it! I just need to get started honestly. What I wanted to do was wrap up my vlogs about simple-calendar and then hop into that after I'm done. Those should be finished in the next couple days.


Hi Chris,

What would you recommend to optimize a partial that is loaded from a helper? You see, I have this partial where I have to call many times 'patient.evolution_notes' but it's querying the database many times. Is there a way I could optimize it, since there's no controller for that specific partial?

Thanks

I would say try your best to eager load as many of the subrecords as you can so that you're not querying as much. You may be able to cache that in the controller instead of the partial and save some query time that way.


Login or Create An Account to join the conversation.

Subscribe to the newsletter

Join 27,623+ developers who get early access to new screencasts, articles, guides, updates, and more.

    By clicking this button, you agree to the GoRails Terms of Service and Privacy Policy.

    More of a social being? We're also on Twitter and YouTube.