-
Notifications
You must be signed in to change notification settings - Fork 171
MAGE-1083 Collection size caching #1764
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
MAGE-1083 Collection size caching #1764
Conversation
… operations dropping parent products
damcou
left a comment
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.
|
Thanks for the great feedback @damcou ! I will implement the changes you've proposed (though some might go on a different ticket). |
damcou
left a comment
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.
Tests are passing, LGTM 🚀

Summary
This PR aims to reduce overhead related to calculating collection size. As catalogs grow in size the query becomes increasingly less performant. By eliminating redundant
COUNT()operations we can shave some processing time here.This PR includes the following changes:
rebuildEntityIds()as a relic ofAlgolia\AlgoliaSearch\Helper\Data::rebuildStoreProductIndex()hereentityIdsareParentsLoadedmember boolean - this internal state was observed to be problematic when processing jobs across stores (parents would not be loaded for subsequent stores) - now should be consistentPlease note that I chose not to address all stock scenarios for cache invalidation until we more properly address MSI. That can be reevaluated at a later date.
Result
Unit tests:

Caching of collection size in Redis:

New indexing cache:

Full index job gen - EXTRA LARGE fixture - uncached:

Full index job gen - EXTRA LARGE fixture - CACHED:
