We’ve observed that users are experiencing frustration due to the extended loading time of filters. Could we consider implementing a caching mechanism for these filter options? This approach, similar to what we employed in Periscope, could potentially bypass the need for time-consuming SQL operations every time a filter change is required.
Holistics does cache the SQL results of the filter. If it took much time for the filter to load, I suspect it’s either when the first time the filter got loaded and there was no cache, or when the cached data of the filter expired and it had to execute SQL query to fetch the data.
We already have some plans to improve the behavior but they are still in discussion and progress, so I can’t share much here as they can be changed when rolled out. If this issue is very annoying and can be a blocker to you, I suggest contacting our support team at [email protected] so we can look further into the issue and have some quick solutions, as each user can have a different issue.
Tip: If users know what they want to filter, they can type in the input and press Enter without waiting for the filter options to be fetched.
To clarify Triet’s response, the cache duration for the filter suggestions is 8 hours. And the caching is done lazily when a user uses the filter.
Regarding the possible improvements, here are the ideas that we currently have in mind:
- Allow adjusting the cache duration
- Allow specifying a fixed list of suggested options
- Support setting up schedules to periodically and proactively prefetch the caches
Let us know if you think any of the above improvements would fit your needs!
From playing around this my preference would be that the cache for filters is set when a user refreshes the whole dashboard either via the web UI (web UI button below) or API.
Secondly even when cached the experience is on the slow side. IMO - this should feel really snappy. For the example I have the cached result takes ~3s which is too long for the user.
I will send a GIF of this via support