-
-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use followers counter cache when available #6383
Use followers counter cache when available #6383
Conversation
The proposal model does not have a `followers_count` column so we need to provide a fallback. Other models avoid an N+1. Then, we need to find out why proposals don't have followers counter-cached. If they did, we would avoid another N+1.
@decidim/core can you review this, please? It improves the performance of the FollowButton cell, thus improving the performance of all indexs pages rendering it. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏 Simple and effective
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
I approve but would like to get rid of followers_count
method would you implement proposal.followers_count
counter cache please? 🙏
@tramuntanal can we do that in a future PR, please? @sauloperez is on holidays and we don't have enough people to take over this PR right now, and this might end up forgotten :( |
Yes @mrcasals , I think it wouldn't be a problem. By the moment, I accept this PR and we'll wait for another PR later with the correction requested by @tramuntanal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch @sauloperez 👍
The proposal model does not have a `followers_count` column so we need to provide a fallback. Other models avoid an N+1. Then, we need to find out why proposals don't have followers counter-cached. If they did, we would avoid another N+1.
🎩 What? Why?
Investigating proposals' performance together with @mrcasals we found out that a considerable amount of the time is spent rendering coauthorships (all that complexity comes at a cost). Among that, a big issue was an N+1 fetching the authors' followers.
We thought a counter cache had to be added but it turns out it already existed 🎉 ! However,
Proposals::Proposal
doesn't implement it and thus, we need to provide a fallback for now. It can be added in a separate PR (I'm not sure I'll get it done before going on holidays)In my machine, this gets from
to
I assume the impact will be noticeable in a production env more than we see here ☝️
📌 Related Issues
📋 Subtasks
CHANGELOG
upgrade notes, if required📷 Screenshots (optional)