How to become a Tableau Server process expert

Have you ever wondered what actually happens in Tableau Server when a user loads a visualization? Do you wish you could correlate user activities to optimizing process configuration for Tableau Server? These are the questions that I used to ask myself constantly, so I decided to build a dashboard that can help answer them.

As an internal product trainer here at Tableau, I have the privilege of teaching our technically focused employees all about Tableau Server. When I first started to learn how to use Tableau Server, I was so impressed that something so complicated was so easy to install and configure. As I started to dive deeper into the product, I realized that although configuration can be simple, it can also be optimized in a myriad of different ways, and it’s not always easy to know what is best for your environment.

To help understand how user behavior affects load on Tableau Server processes, I created the Tableau Server Process Scenario dashboard:

To use the dashboard, select the workflow you would like to observe, then choose the data source type. You can then progress the slider to move through each stage of the workflow and read a description of what is happening at each step below. The workflows are updated for Tableau Server 2019.2, so if you are not yet familiar with Ask Data or Prep Conductor, you can study the new scenarios for those processes before you upgrade.

Knowing when each process is utilized will help you optimize Tableau Server for your particular needs, and guide you in configuring processes. For example, knowing that Backgrounder only interacts with a few other processes is one reason why we recommend configuring isolated Backgrounder nodes in environments with lots of extract refreshes. Other examples of configuration advice are:

• Gateway is involved in any user initiated action, and will always pass the request directly to the Application Server. That means Gateway should always be configured alongside the Application Server, so that requests have a chance of being fulfilled on that node.
• VizQL almost always receives a request from the Application Server, so placing these two processes on the same machine increases the chance the request gets fulfilled on that node.
• The Repository is accessed in almost every workflow, and by many different processes. Since there can only be one active Repository configured, attempting to co-locate the Repository with other processes is largely not helpful. Instead, isolating the Repository by itself can avoid resource contention with other processes, and increase total throughput for Tableau Server.

If you want additional information on how to optimize for different use cases, our newly updated Performance Tuning Online Help page is an excellent resource.

Of course, even the best products occasionally encounter unexpected behavior, and being able to locate the source of an issue is a crucial skill of any Tableau Server Administrator. Now you can trace an action in Tableau Server across each process, which will enable you to take action immediately.

For example, while building this dashboard I learned that Data Server is only accessed during requests to published data sources. If you are using embedded data sources (data source is not published separately from the workbook), then Data Server will not be used, even if the connection is live. Now I know that I don’t need to check the Data Server log if I’m looking for a connection to an embedded data source. Don’t know where each process log is located? Check out the Server Log File Locations page.

I hope you find this workbook as useful as I have, and that it helps make you a more efficient Tableau Server administrator. Keep an eye out for updates as we continue to add new features and processes to Tableau Server!