Isolating Tableau Server Performance Issues

In this post, I’ll be describing a set of steps to follow to isolate the causes of performance issues on Tableau Server.

Here are the basic steps:

  1. Test the workbook in Tableau Desktop. Does it perform well? If yes:
  2. Test the workbook in Tableau Desktop on the Tableau Server machine. Does it perform the same as it did on the previous machine? If yes:
  3. Publish the workbook to Tableau Server, and find a time when there is low-to-no usage on the Tableau Server. Go to the published workbook. Did it perform relatively the same as the test in Step 2 (within 1-3 seconds)?  If yes:
  4. Test the workbook during a time of high usage on the Tableau Server (either natural or do load testing using TabJolt).



Pre-aggregating data with full drill-down

Have you heard this one before? “Just connect to your data in Tableau and start visualizing. Then you’ll publish and share with your whole organization.” It’s a great line, because it’s true. You CAN get started with analysis on top of just about any data in Tableau. But “can” is not “should” — what is possible may not be the BEST way, particularly if you want to scale up. When dealing with massive amounts of data, a better solution is to have two data sources: (1) A pre-aggregated data set for overviews, which I’ll call the Overview data source (2) The row-level data set, which I’ll call the Granular data source. Tableau’s abilities to filter between two data sources (actions & cross-datasource filters in Tableau 10) make this an excellent strategy, and one that I have seen massively improve performance over and over.


Caching in Tableau Server and Row Level Security

Tableau Server, particularly since the 9.0 release has  fantastic caching mechanism. Once a view has been loaded into the cache, any subsequent view using the same data will load extremely quickly. This is why you may notice that a first view in the morning takes some amount of time to load, but every other view is much quicker. Some Tableau customers even “warm” the cache on some of their views by scheduling an e-mail or pinging the Tableau Server for a request of a PDF early in the morning, before any of the regular viewer come in. You can even force a refresh using the “warming” technique by appending the :refresh parameter to the end of your request.


Performance tip: Use “Selected Fields” in Dashboard Actions

When you are trying to maximize performance in Tableau, particularly on a live connection, sometimes the smallest changes can make a big difference. All of your choices in Tableau Desktop eventually end up as a real live SQL query, which the database will have to interpret. The simpler the query, the easier the interpretation, and in most cases the quicker the results.

generated action

Tableau’s Dashboard Actions are amazing, and in the newer versions there is a quick little “Use as filter” button on each sheet in a Dashboard. This creates an Action in the Dashboard->Actions menu which is set to “All Fields” down at the bottom. This is incredibly convenient from a creation standpoint; however, it means that the selected values for every single dimension in the Source Sheet will be passed along as filters in the WHERE clause of the eventual SQL query. This includes categorical information which you are displaying: if you are showing Product Category, Product Sub-Category, and Product ID; all three will be sent in the eventual query.

Particularly when you are getting down to granular details, you really only need the most granular piece of information to be passed into the WHERE clause. For optimal performance, you really only want to pass in values for fields that are indexed in the database. In the previous example, presuming that a Product ID can only belong to one Category and Sub-Category, setting the Action to “Selected Fields” and choosing “Product ID” would simplify the query sent; hopefully Product ID is indexed and thus you get an incredibly quick lookup.




Using a “Hidden” Sheet for Advanced Action Filtering

Learning to design so that you limit loading unnecessary rows of granular data is the most important technique you can learn to make Tableau perform well. It reduces the strain on the database in finding and returning data, and it limits the amount that Tableau needs to return. Ask yourself: “Am I getting tired of scrolling through this list trying to find what I need?” If the answer is yes, consider what other views of the data might help you filter down just to the rows you need to see.

Setting Actions to Exclude when nothing is selected

The ideal workflow in Tableau, both from a performance and a visual analysis perspective, is useful visualizations that filter via Dashboard Actions that act on click / select. You can limit what is shown by setting your Actions to Exclude when nothing is selected. After the first time you do a selection and clear it, the affected sheets won’t show anything until something has been selected.


Tableau on Azure

“Tell us about Tableau on Azure”. “Does Tableau run on Azure?” There is probably no more confusing question at the moment, because the terminology for Microsoft Azure is unclear, and Microsoft have been making changes to both the technology and the nomenclature so quickly that it’s best to step back and understand the ways in which Tableau can interact with the Azure platform.

There are three different situations can fall under the “Tableau and Azure” moniker, all of which are possible:

  1. Tableau Server hosted on a Virtual Machine in Azure
  2. Tableau Desktop or Server connecting to the Microsoft run and operated Azure SQL Database
  3. Tableau Desktop or Server connecting to a database (often Microsoft SQL Server) on a hosted Virtual Machine in Azure

Tableau Server on a hosted VM

Much like AWS, Tableau Server can be run on a hosted VM in the Microsoft Azure cloud. Russell Christopher has done an excellent job of testing out the available VM and storage configurations available in Azure and making recommendations on what is necessary for good performance with Tableau Server. If you want to host Tableau Server on Azure, stop now and read Russell’s blog.

In virtualized environments, disk access / IOPS tends to be the biggest hidden issue for Tableau Server performance, particularly if you are using extracts. This is true of Azure, AWS, and also your internal VMWare configuration.

The official Tableau KB article on installing Tableau Server on Azure is now available here .

Tableau Desktop and Server connecting to Azure SQL Database

Here is where the wording gets fun (i.e. confusing). As if “SQL Server” wasn’t already a generic enough name, Microsoft refers to their managed and hosted cloud database, based on “SQL Server”, as “Azure SQL Database”. Internally, it is very similar to SQL Server, and as of Tableau 9.1, you simply connect via the standard Tableau native connector for Microsoft SQL Server. Put in your credentials, and you are good to go.

Tableau Desktop and Server connecting to a Microsoft SQL Server database on a hosted VM in Azure

You can also put a database (usually Microsoft SQL Server) on a hosted VM in Azure. Luckily, to Tableau Desktop and Server, the process for connecting is identical to that of any SQL Server connection: put in your credentials and viola!