Describe the bug
Our worst-case scenario on article show pages is an n+1 problem. We do a fair amount of caching and we have a somewhat efficient approach to not make literally every query. But still, we do extra queries on some requests, and when a page with a lot of comments gets loaded cold, it can be a big outlier in performance.
To Reproduce
Create an article in development and add a bunch of comments at different levels. You should see lots of queries happen.
Expected behavior
A single query should be enough to load all the comments into memory. All comments that belong to an article have a commentable_id of that article, even sub-comments. We use the ancestry gem to handle the tree logic.
Since we can grab all the comments that would be part of the tree with a single query, we should be able to only ever make a single comments query and then work on that set from there.
I think the solution would be something along these lines:
Of course, everyone is welcome to peruse the open dev.to issues for bugs and features they can take a stab at.
I just created this issue if anyone wants to take a look on the Ruby backend side of things:
Describe the bug Our worst-case scenario on article show pages is an n+1 problem. We do a fair amount of caching and we have a somewhat efficient approach to not make literally every query. But still, we do extra queries on some requests, and when a page with a lot of comments gets loaded cold, it can be a big outlier in performance.
To Reproduce Create an article in development and add a bunch of comments at different levels. You should see lots of queries happen.
Expected behavior A single query should be enough to load all the comments into memory. All comments that belong to an article have a
commentable_idof that article, even sub-comments. We use the ancestry gem to handle the tree logic.Since we can grab all the comments that would be part of the tree with a single query, we should be able to only ever make a single comments query and then work on that set from there.
I think the solution would be something along these lines:
stackoverflow.com/questions/322073...
Thanks!
Ironing that out would greatly improve worst-case-scenario page loads on posts with lots of comments.