We have a dashboard ( might turn out to be a few ) which we need to be as near instantly rendered as possible when a consumer opens it.
I recall at some point there being a "warm up" setting but not that it was dashboard specific.
So - is there a way we can prioritize that dashboard ( or underlying tables? Queries? ) to be 1) read into memory in advance of a user opening the dashboard and 2) have it stay in memory so the dashboard always gets the highest priority performance?
Corollary - after reading @Tristan's excellent article ( https://community.incorta.com/t5/dashboards-analytics/dashboard-design-for-performance/ta-p/219 ) I understand each security filter version is cached individually. The article is from last year - is that still the case?
Given that we will have row-level security is there anything we can do to prioritize the single or group of dashboards?
Solved! Go to Solution.
Hi @RADSr ,
We do have 2 scopes of caching that helps faster rendering of dashboards:
For the column caching, columns are loaded to memory first time it is used and cached until evicted, either due to underlaying schema refresh or tight memory.
For the insight's query result sets caching, they are calculated first time, then cached until either the underlaying columns/schemas refresh or no enough caching memory. To rerun and cache those result sets, you can do the following:
@Prince I'm just starting down this road, so near-completely uninformed about how this might be possible in Incorta, but if I were to create a new analytics node w/in my cluster can I create routing rules per dashboard to make sure I have 1) reserved memory for those insights and 2) a much lower turnover of cached query results? I'm really curious about creating routing rules for both this use case and a case where we would have an outside API query against our cluster.
Even a pointer as to where to start learning about this will be helpful.