5 Tips to Improve the Performance of Your Tableau Server

By Bill Medrano 01 Sep, 2016

You already know that Tableau Server is a powerful collaboration platform. It lets you easily share and distribute the workbooks and dashboards you create in Tableau Desktop. Because people across your organization depend on Tableau Server, it’s essential to keep it performant and scalable.

Follow these five tips to improve the performance of your Tableau Server, streamline your admin tasks, and make sure your investment is ready to scale.

1. If You Have Active Directory, Use It from the Start

There are two ways your users can authenticate on Tableau Server:

  • Using local authentication where Tableau Server keeps credentials internally
  • Using Active Directory

If your enterprise uses Active Directory, install your Tableau Server using Active Directory authentication from the beginning. Here’s why: Tableau Server assigns ownership to each piece of content. Therefore, all content created while using local authentication will be owned by local users. Once you switch to Active Directory, none of those local users will be able to own content since all local users will become “unlicensed” and all users must have credentials in Active Directory.

2. Use Functional Permissioning

This skill will make all the difference when scaling your Tableau Server. If used from the start of your Tableau Server journey, it allows you to save countless hours administering content permissions.

The idea here is to form groups that are determined by the functions that different groups of people will have on specific content. For example, let’s say that your company’s internal audit team has content on your Tableau Server. At the project level, the team has one project for the Annual Audit Plan. There will be two different functions that users will perform:

  • Publishers: This functional group will publish content to the Annual Audit Plan project. It will contain authors from the internal audit team.
  • Interactors: This functional group contains users who can interact with content. These users will come from several different parts of the organization and might include the CFO, the board of directors, the COO, team members from legal and compliance departments, and so forth.

Functional permissioning allows Tableau Server administrator to apply group permissions based on what users do with content instead of applying organizational permissions based the user's department. That will help you avoid two common mistakes:

  • Assigning permissions to content at the individual user level: Once you start down this road, as your installation scales, managing permissions becomes time-consuming, and debugging permission cases becomes confusing. It is a burden at 25 users; it becomes unwieldy at 2,500.
  • Using organizational permissions: For example, you can create a sales group that has every salesperson in it, then assign permissions to content for the organizational group.

3. Understand and Monitor Tableau Data Extracts

Tableau Data Extracts are a hugely powerful tool when implemented correctly. Once extracts are created and published to a refresh schedule on Tableau Server, they can grow unwieldy over time. Techniques to optimize, identify, and monitor extracts are crucial to the health of your server.

For example, most large extracts can contain a lot of unused data. With regular refreshes, the extracts can grow and consume a lot of resources unnecessarily. Therefore, it’s important to follow these three best practices as relates to extracts:

  • Hide unused columns: Tableau will determine which columns are used in your workbook at extract-publication time and hide all the others.
  • Aggregate to the highest visible level of your views: If your sales chart shows monthly sales by region, the select this option to sum up sales activity by month and region.
  • Filter your data: When you’re doing a year over year comparison, for example, filter out any historical data that won’t be used in the view.

When implemented, these best practices are powerful. Look at the example below where we reduce the size of the extract from 3.5 GB to 7.6 MB. The record count goes from 215 million rows to just 64 rows.

You get the same results from the two extracts.

4. Construct a High Availability Tableau Server

Many customers want a high availability Tableau Server, one that provides real-time content replication and failover support. Since extracts and repository data change rapidly, a high availability Tableau Server will provide you with greater protection from system failure than regular backups can.

In order to build one, you must have process redundancy, a backup primary, an external load balancer, and enough nodes to provide a quorum.

5. Implement User Filters

This valuable technique lets you automatically control which users see what data, and allows your dashboard developers to create more flexible views.

The way this works is that Tableau Server will recognize the user that is logged in, and will apply logic to determine which rows of data that individual user can see. The filtering logic can be a simple yes or no based on a characteristic of the data. It can also be the result of a more complex relationship between the user and another dimension—for example, which department the user is in.

Oftentimes, dashboard authors will create different versions of the same view for different users due to data-access permissions. This causes more testing and more complication, and consumes more resources. By implementing user filters, the same view will let each user see only the data he or she has permission to view.

To learn how to implement these five tips, sign up for virtual or in-person training on Tableau Server administration and Tableau Server architecture.


Submitted by Alex B. on

Lots of good tips. I've definitely seen the waste of effort from defining groups based on the current years org chart instead of functionally based on what kind of data people can see. So heartily second that tip.

When advocating user filters though, people should be aware that the prevent using much of the cache on Tableau Server for obvious reasons, so can have a performance impact on heavily accessed views. If you only have a few levels (say a manager view and a worker view), different views might perform better sometimes.

Submitted by Heng (not verified) on

Great stuff Bill!

Submitted by Ryan R (not verified) on

#3 is great but it would be much easier to monitor if those stats (row count, size) were shown in the server. Having to download and inspect each data source doesn't scale.

Submitted by Bill Medrano (not verified) on

Hi Ryan: You can connect to your repository's datasources table and easily get the size of each datasource. Using Tableau desktop, put "Name" on rows and "Size" on text. If you want more information about extracts, join the extracts table to datasources using "id" from datasources and "datasource id" from extracts.
Hope that helps.

Submitted by Ryan R (not verified) on

Thanks for the response Bill but I have a couple follow up questions/comments.

1) connecting to the backend to get the data while useful seems like an unnecessary step. I would argue/advocate that it should be in its own column workbooks. (Much faster and easier for any user to monitor the size of extracts as opposed to just the admins).

2) Above its a little confusing as I didn't realize at first that these were Data sources that have been uploaded to the server. On our instance we have workbooks with extracts that are uploaded. There is very little if any overlap between these extracts so we don't use datasources. That being said it would be really helpful to have the size of these extracts listed on the server as well. Currently if you go to a workbook > Data sources (next to views) you are presented with [Name | Connects to | Live/Last Extract | Alert]. It would be very helpful to have the size listed there as well (for all of the reasons listed above).

2b) Note I did find the table you mentioned for datasources complete with the size column. However this table only had 11 records (due to our usage pattern above). Whereas the table extracts had 1,000+ records. However, the extracts table only had the columns [id, workbook_id, descriptor, created_at, updated_at, datasource_id] No Size column.

3) In summary Tableau is a very user-friendly tool and I'd argue that including the size (maybe row count too) of datasources & workbook extracts in a very visual manner similar to the way you've presented views information would further advance Tableau's usability.

Submitted by Bill Medrano (not verified) on

Thanks for the comments Ryan, and I agree with you.

As long as you are a Site or Server Admin, you can see the sizes of extracts by accessing the "Stats for Space Usage" via the Built in Admin views on the "Status" page.

Once you get to the "Stats for Space Usage" view, you'll probably want to set the "Min size" setting down to zero if you want to see every extract, and then set the Extract drop down to "Extract". You'll see the sizes of all extracts; it doesnt matter if you got the extract to server by publishing a workbook or if you simply published the extract as a data source. This view finds all extracts in your site or server, depending on your site role and your selected scope.

Note: Row count is not shown, if you were curious, just navigate to the Data Source page, select the extract you're interested in, create a new workbook, and just drag "Number of Records" to the label shelf on the marks card. I know that's not optimum, but it is a usable work around.

If you want me to demo any of this for you, send an email to bmedrano@tableau.com and I'll get a WebEx going.


Neuen Kommentar hinzufügen 

non-humans click here