- Issue created by @azinck
- 🇺🇸United States azinck
I've opened a merge request with these optimizations. The improvement is dramatic. After label, section, and collection data has been cached the initial load of the media library has gone from about 7.5 seconds down to about 1, and every interaction with the filters has gone from a whopping *20 seconds per interaction* to just 1 second per interaction!
Previous to this optimization, every interaction with filters entailed a full 71 requests to the BF api for me (your numbers will be at least partially driven by the number of labels in your BF instance)! The optimization gets this down to 1 request.
I've arbitrarily chosen a 10 minute cache TTL for the label, section, and collection data. I want them to reflect changes in BF in a relatively timely fashion while still benefitting from the caching. I could see exposing this as an option to users, or even letting the user choose to have the cache never expire and forcing the user to do a manual re-load of their BF data if it's stuff that changes extremely seldom. But a 10 minute TTL seemed like a reasonably balanced starting point.
- 🇺🇸United States ndewhurst USA
Hi azinck, I definitely agree with the direction here. Labels in particular can be time consuming currently.
I'm working on performance improvements for the 6.x branch, which has a number of other changes, but I'm open to approving this for the 5.x to help users more immediately & broadly. Can you update the MR to make the cache lifespan configurable?