-
-
Notifications
You must be signed in to change notification settings - Fork 708
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
Admin Customers performance #5196
Admin Customers performance #5196
Conversation
691e57e
to
09a51ca
Compare
09a51ca
to
c8af1cd
Compare
c8af1cd
to
62e4dd0
Compare
@@ -17,8 +17,9 @@ def index | |||
respond_to do |format| | |||
format.html | |||
format.json do |
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.
It would be really nice to extract this to the API, but I think it would require a lot more changes to be piled on top of this PR...
Fixes N+1 queries on customer tags
62e4dd0
to
4c41c84
Compare
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.
awesome!
I think we should try to look for other places where tags are killing us and improve 👌
I just double-checked some of the SQL before and after and I realised I forgot something crucial here! It's a polymorphic association, so we have to specify the class the tags are attached to: New commit added. Hopefully we can extract this into a reusable service as some point and utilise it elsewhere. |
I had a quick look and it looks like we can use this to improve reports 💪 |
awesome, we should create an issue for that like: extract customer_tags_by_id and re-use it 🎉 |
if credit_cards.loaded? | ||
credit_cards.to_a.find(&:is_default) | ||
else | ||
credit_cards.where(is_default: true).first |
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.
have you tried defining this as an association and using AR association's :condition? This feels to me like something AR should do and not us.
We can improve it in a different PR if you prefer. I don't want to delay this PR.
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.
👏
Hey @Matt-Yorkley , Uff. This one was a brainer to set up - and, well, made me very grateful this and all performance efforts :-) In AU and as superadmin:
Somehow, I could not "measure" a tangible difference... Load times for the /admin/customers/ page: Perhaps the customer number isn't large enough? I'm moving this to ready to go, but adding the feedback label, just in case you feel there is anything more I should try here. |
Thanks Filipe! Interesting results. I just had another look, and the optimisations here will apply more to larger hubs that have any/all of the following:
I think Prom Coast Food Hub is a good one to go for if you're testing large hubs on Aus Staging. |
Ah - that one has over 600 customers. I guess I should just have asked :-) |
Ok! Now things look quite different. Time to refresh page: Time to display data, after clicking the [ Show all (589 more) ] button: Thanks for your help @Matt-Yorkley |
What? Why?
Improves performance in admin customers page.
What should we test?
Admin customers page is working correctly, should be much faster for large hubs.
Release notes
Improved performance on admin customers page
Changelog Category: Fixed