Tableau Dashboard Performance Series: Tip#35: Tableau Server Load

This happens to fall in the last category where there are certain items that are completely out of control for business teams.

However, having additional information hasn’t even hurt anyone. So, if time and again, you just need to ask your IT counterparts if the servers has enough hardware and it keeping up with the load of the users and the usage, they may appreciate that. In fact, you might need to prepare for some funding too so you can not only ask the right question but offer to help provide $ needed to ensure your success.

Tableau Dashboard Performance Series: Tip#34: Database Load

This happens to fall in the last category where there are certain items that are completely out of control for business teams.

However, having additional information hasn’t even hurt anyone. So, if time and again, you just need to ask your IT counterparts if the database that you are using to analyze your data has enough hardware to support the load on it.

In fact, often times, for enterprises, the data strategy involves setting up databases that support analytical loads. But, unfortunately, once these databases are setup, they are not often maintained how they should. Feel free to contact me if you would like to talk more about this

Tableau Dashboard Performance Series: Tip#33: Data Structures

This happens to fall in the last category where there are certain items that are completely out of control for business teams.

However, having additional information hasn’t even hurt anyone. With data structures, we often mean that data is typically setup in tables and columns and the design of such tables and columns can have an impact on your dashboards.

What??? Yes, think of a table that was created for all possible needs for many different analysts and users. There is no way that all possible adhoc queries can be thought of ahead of time. This may mean that for certain production use cases for operational reporting, you may end up revisiting the data structures after you have decided on fixed set of requirements.

For ad hoc analysis, use Tableau Prep and Tableau extracts , IMHO.

Tableau Dashboard Performance Series: Tip#32: Database Tuning

This is a big topic and often, NOT, something that an analyst of a business user needs to understand or care about.

And typically outside of your control. Having said that, if you can create an extract that is performing better than the analytical DB that you are provided access to, you may want to show the performance on extracts and have your DB team work on tuning so you can EXPECT similar performance.

Tableau Dashboard Performance Series: Tip#31: Right-sizing the data for analysis

Another interesting one with many reasons for debate here.

Every time, I bring this up, I have many hands at my customers asking why they shouldn’t be allowed to do the analysis against their entire dataset. And, I always take the example of finding the needle in the “proverbial haystack”. You will always need a strategy to take a chunk of data at a time. You will always need to make a hypothesis and prove it wrong, by taking chunks of data and doing the same analysis against it over and over again.

Now, you can use automated methods of analysis including some data science techniques, but at the end of it, you will always need to understand what is a good chunk of data to slice at a time.

Use the same logic to decide what’s worth analyzing for a particular dashboard. All the performance strategies over the last 2 decades have been many versions of the same thing.

Pre-aggregates, cubes, caches, reflections, lenses, etc.

At the end of the day, you are doing something to shrink the data to “useful set of data” and I ask you to utilize your common sense here.

  1. At times, this will mean creating separate extracts from the same data source for different purposes
  2. At times, this will mean using smart filters
  3. At times, this means limiting the rows of data in your extract
  4. At times, this means utilizing Prep to create an extract with pre-aggregated fields inside

Hope you get the idea, if not, shoot me a Q