Optimise for User Traffic
You can optimise for traffic if you have many active Tableau Server users and few published data sources that need extract refreshes.
When to optimise for user traffic
Slow load times for views
Use the Requests and Sessions dashboard of the sample performance workbook to analyse how long views take to load.
If multiple views take longer than 10 seconds to load, and if the slow load times correspond to a large number of sessions, that can indicate that user traffic is slowing down the server.
However, if a particular view takes a long time to load regardless of when it is viewed, it's a sign that the workbook for the view needs to be optimised. You can identify which workbooks need to be optimised with the Stats for Load Times administrative view. Some simple ways of optimising workbooks includes displaying less information in each view or breaking up views, reducing the number of filters, and using data extracts.
High resource usage corresponding to user traffic
If your server displays high CPU and memory usage during peak traffic hours, you should optimise for user traffic. To determine peak traffic hours and analyse how many concurrent users are on your server, use the Users and Actions dashboard. In addition, you can use the Traffic to Views administrative view to see how much user traffic involves accessing views (as opposed to performing administrative functions, publishing, or other tasks).
If you click a point in the Number of Users view, the dashboard displays the users that were active at the time and the number of user actions that those users performed. By default, the only user actions displayed are user views, but you can use the Action Types filter to display additional user actions.
Make a note of the times of day when there are many concurrent users and views so that you can compare this to resource usage. As a rule of thumb, the number of users should correspond to a high number of user actions. However, the view in this example displays an artificially high number of actions for a single user as part of a load generation test. As an example, you can compare the high number of views at 12 AM on June 28th with the resource usage in the dashboard illustrated later.
Use the CPU Usage dashboard to display the percent of total CPU usage and the percent of CPU usage for each process. In the following example, note the large spike in total CPU usage and in the VizQL server process at 12 AM on June 28th. Because the VizQL server process loads and render views, the VizQL server process is often the first process to show strain under high user traffic.
Note: The percent of CPU usage for individual processes may add up to more than 100 percent. This is because processor utilisation for individual processes is measured for a given processor core. By contrast, the total CPU usage is measured for all processor cores.
Use the Memory Usage dashboard to display the percent of total memory usage and the average memory usage in gigabytes. As a general rule, memory usage increases steadily with user traffic. Here again the VizQL server process is the first to show strain under high traffic.
Ways to optimise for user traffic
When high user traffic corresponds to high resource usage as it does in the example shown previously, you should optimise for user traffic.
Adjust the number of VizQL server processes
The most effective way of optimising for user traffic is to adjust the number of VizQL server processes. Add one VizQL server process at a time and measure the effect with more performance monitoring. Because VizQL server processes can consume a lot of CPU and memory, adding too many processes can slow down the server instead. If you see consistently high memory usage, try to reduce the number of VizQL server processes to reduce the amount of memory reserved.
For more information about configuring processes, see Configure Nodes.
Adjust the number of other processes
Although the most effective way of improving performance for user traffic is to adjust the number of VizQL server processes, you can also tune other processes that support the VizQL server process or that prevent the VizQL server process from accessing resources. For example, the VizQL server process makes frequent requests to the cache server process, so you might also want to increase the number of cache server processes. On the other hand, the Backgrounder processes might contend for CPU resources with the VizQL server process. As a result, if you do not need to run frequent extract refreshes, you might reduce the number of processes for the backgrounder. If you do need additional instances of the backgrounder, and if you're running Tableau Server on a cluster, you can move the Backgrounder process to a dedicated node.
Adjust the VizQL session timeout limit
In the example shown previously, the amount of memory used by the VizQL server process increases with user traffic, and it remains reserved by Tableau Server for some time after the traffic finished. This is because the VizQL server process reserves memory for each session for a specified amount of time. If the VizQL server process uses a high percentage of the available memory, try reducing the timeout for each session to make memory available more quickly.
To do this, use the tsm configuration set command to reduce the vizqlserver.session.expiry.timeout setting. The default is 30 minutes.
Refresh the cache less often
If your users do not always need the most up-to-date data, you can optimise for user traffic by configuring Tableau Server to cache and reuse data as much as possible.
To do this, use the tsm data-access caching list command to confirm the refresh frequency. The default is Low. Use the tsm data-access caching set command to change the refresh frequency.
Assess view responsiveness
When a user opens a view, the components of the view are first retrieved and interpreted, then displayed in the user's web browser. For most views, the display rendering phase occurs in the user's web browser and in most cases, this yields the fastest results and highest level of interactive responsiveness. Handling most interactions in the client web browser reduces bandwidth and eliminates round-trip request latencies. If a view is very complex, Tableau Server handles the rendering phase on the server instead of in the client web browser, because that generally results in the best performance. If you find that views aren't as responsive as you'd like, you can test and change the threshold that causes views to be rendered by the server instead of in the client web browser. For more information, see Configure Client-Side Rendering.