Do hidden visuals and unopened tabs impact performance?

This is a three-parter… thanks!

HIDDEN VISUALS
Do hidden visuals impact performance of the dashboard? I have some tabs that are starting to get slow, and they have about 40 visuals on them (over the recommended 30). However, no more than 30 of them will be showing at one. I am hoping to find out if this is one of the reasons my tabs are loading slow.

UNOPENED TABS
Also, do unopened tabs also impact performance, or do they only load once they are clicked on? Said another way, will reducing the number of tabs improve dashboard performance? I know its suggested to remove unused datasets, and was wondering if this is the same for tabs.

SPICE TRADEOFF
What would be faster, a large SPICE table (30GB) that repeats many values (aka the LEFT JOIN was done in Athena beforehand). Or, a smaller SPICE table (14ish GB), that does the LEFT JOIN within the quicksight dataset. I am wondering if there is a space-time tradeoff here, because for the larger dataset, quicksight would not have to do left join calculations. However, I’m do not know how SPICE works and am wondering if this tradeoff applies to SPICE.

Thanks!

I did a test by creating hidden visuals and creating visuals in an unopened tabs in QuickSight by using RedShift as data source.

HIDDEN VISUALS: If the visuals are hidden, query will not be executed in Redshift
UNOPENED TABS: If the visuals are located in unopened tabs, query will not be executed unless user click on the unopened tabs.

SPICE TRADEOFF: I am checking, will getback soon

1 Like

To chip in regarding the last point, in short I do not think there is a one size fits all solution.

Ultimately, the question of whether to do the join in Athena and importing directly in QuicksSght or creating a QuickSight dataset and then join at the data prep level, will affect the query ingestion time only and not performance of visuals using that dataset.
( Also, even if you import this using parent-child dataset you will still only be affecting the ingestion time. You can see here Creating a dataset using an existing dataset in Amazon QuickSight - Amazon QuickSight

  • Direct query is supported for a single SPICE parent dataset. It is not supported for multiple SPICE parent datasets in a join.

This means that if you want to do the join in QuickSight, you would need to create a new SPICE dataset meaning that differences in time will only affect the ingestion time.
However, this approach uses more space and I wouldn’t suggest pursuing this
)

Of course, since this is using Athena underneath, join performance on Athena depends on how optimized the data is and how optimal is the join you are performing. There are a number of best practices for querying data in Athena and in particular for joining data in Athena … it is always good to follow them regardless). see Top 10 Performance Tuning Tips for Amazon Athena | AWS Big Data Blog
However, with SPICE you are working with an optimized in memory engine so I would not be surprised if the total ingestion time is lower if you let it do the join - so ultimately you’d need to test with your data to determined which is the best.

My suggestion would be to first try keeping the join in Athena. This is primarily because:

  • QuickSight joins are rather limited whereas Athena JOIN support more complex/standard SQL joins
  • For heavier joins, newer Athena version (from version 2 onwards), Athena can offload the join to disk. Not sure how QuickSight handles this though.

So, after trying the above, if the ingestion time is not acceptable then you can look at the other option of doing the JOIN in SPICE.

2 Likes

Thank you! I am using SPICE, not direct queries, but I imagine that the requests to the dataset execute the same regardless of the source.

1 Like

Thanks for the detailed response. Good to know that where I do the join does not effect the dashboard performance, only the query ingestion.

The only thing I do not understand is when you say

This means that if you want to do the join in QuickSight, you would need to create a new SPICE dataset meaning that differences in time will only affect the ingestion time.
However, this approach uses more space and I wouldn’t suggest pursuing this

Why would doing the join in QuickSight ever take more space? Even though I am importing two glue tables instead of one from Athena, these tables together are naturally smaller than the large table created when a join is done on them, where the result has many repeated values. And in my method, I would be doing the join in a single SPICE dataset (instead of making a SPICE dataset with 1 table, and then building a second direct-query dataset on top of it to join the second one).

I like the Athena Tuning article too… I need to start partitioning my data beforehand!

@Louietouie to clarify, my comment about the tables taking more space was if you were to import the tables as two SPICE datasets and then use those datasets in new dataset (see Creating a dataset using an existing dataset in Amazon QuickSight - Amazon QuickSight) to create a third SPICE dataset.

2 Likes