Dashboard Load Time - Performance Improvement

Q&A
,
1

Hello!

I have a claryfing question about dashboard performance improvement with SPICE datasets and lots of analysis calculated fields.

I’ve already read a lot of other posts with regards to the performance improvements and one of the most frequent recommendations (apart from not using pivot tables or simplifying them + using SPICE) is to move calculated fields from analysis to the dataset.

I have a use-case when analysis calculated fields are very often based on the analysis parameters that are controls the user can interact with, i.e. the selected values of these parameters are propagated to the calculated fields.

I can create parameters in the dataset, link them with the analysis parameters, and then create calculated fields in the dataset using these dataset parameters, the values of which are updated when user interacts with the analysis controls.

My question is - is there going to be any performance improvement at all in this case of having calculated fields in a dataset that uses dataset parameters the values of which are controlled via analysis controls? In my opinion there will no be performance improvements because the calculated fields in this case will not be precomputed in the SPICE and will be computed when visual loads. Let me know please whether I’m right or wrong here!

One improvement that we are trying to do is to move away from Pivot tables to just tabular tables where possible, because we think it might provide some performance improvements considering that pivot tables are very heavy in loading. Not sure how much of performance improvements we could get - let me know please your thoughts here as well!

Also, what would be the recomendations with regards to performance improvements here? We can’t pre-aggregate data in Athena, because again the parameters are required. Any advise is appreciated!

Thanks!

2

Hello Ksenstad,

Let me try to address your questions about Quick Sight performance optimization:

  1. Regarding calculated fields with parameters: You’re correct in your assessment. Moving calculated fields that depend on user-controlled parameters from analysis to dataset level won’t provide significant performance improvements. This is because:

  • The calculations still need to be performed at runtime when parameter values change

  • SPICE can’t pre-compute these values since they depend on dynamic user input

  1. Regarding Pivot Tables vs. Regular Tables: Moving from pivot tables to regular tables can indeed improve performance because:

  • Pivot tables require additional processing to reorganize data

  • They typically handle more complex calculations and transformations

  • Regular tables have simpler rendering requirements

  • The performance gain may be notable, especially with large datasets

Recommendations for performance improvement:

  1. Data Structure Optimization:

  • Pre-aggregate data where possible (for non-parameter dependent calculations)

  • Remove unnecessary columns

  • Use appropriate data types

  1. SPICE Best Practices:

  • Keep frequently used calculations in SPICE where they don’t depend on parameters

  • Use incremental refreshes when possible

  • Optimize import schedules

  1. Visual Design:

  • Limit the number of visuals per sheet

  • Use pagination for large datasets ( reports non interactive)

  • Consider using filters at dataset level where applicable

  • May be break complex dashboards into multiple sheets

  1. For Parameter-dependent Calculations:

  • Try to minimize the number of parameter-dependent calculations

  • Consider using filter controls instead of parameters where possible

  1. Query Optimization:

  • Use filters efficiently

  • Avoid unnecessary joins

  • Consider materialized views in Athena for common query patterns

those were some of the things that came to my mind but again other members can put more insight on this

Remember that performance optimization is often an iterative process requiring monitoring and adjustments based on specific use cases and user patterns.

Hope this gives some insight.

Cheers,

Deep

1 Like
3

Hello @Deep ,

Thanks a lot for the reply and also some of your recommendations, ideed insightful!

I have actually another question about hidden (unless the rules are compliant) visualisations. Can they slow down the dashboard loading time or since the visual is hidden and only when rule complies the computations are performed, then actually it’s not that much of an impact?

4

Hello Ksenstad,

In my opinion, When using calculated fields with conditional visibility rules in Quick Sight, the impact on dashboard performance is generally minimal because:

  1. Hidden visuals do not execute their queries until they become visible

  2. The calculations are only performed when the visibility conditions are met

  3. Quick Sight uses in-memory computing (SPICE) which helps optimize performance

However, there may be few considerations i can think about:

  1. The initial dashboard load might have a small overhead to evaluate the visibility conditions

  2. If multiple visuals become visible simultaneously due to rule conditions being met, there could be a momentary performance impact

  3. Complex conditional rules might add some processing time, but it’s typically negligible i think

Overall, using conditional visibility rules is an efficient way to manage dashboard content and shouldn’t significantly impact your dashboard’s performance. The benefits of improved user experience and cleaner dashboards usually outweigh any minor performance considerations.

I hope this helps.

Cheers,

Deep

1 Like