How to diagnose and fix Tableau Server performance problems — the tools for measuring server health, the configuration parameters that matter, workbook-level performance patterns that cause server load, and the operational practices that prevent performance degradation over time.
Tableau Server performance problems have predictable causes. The causes fall into three categories: server configuration that is not optimised for the organisation's workload, workbooks that are engineered to be slow, and operational degradation that has accumulated over time without active management. This guide covers how to diagnose which category your problem falls into, and what to do about it.
Measuring Server Performance Before Optimising
Performance tuning without measurement is guesswork. Before changing anything, establish baselines.
### Tableau Resource Monitoring Tool (RMT)
The Resource Monitoring Tool is Tableau's dedicated server health monitoring application. It requires a separate server process and a licence that is included with Tableau Server Enterprise. If you have RMT deployed, start here.
RMT provides: VizQL server process CPU and memory utilisation, backgrounder job success rates and durations, concurrent sessions and users, extract refresh queue depth, and alerting on defined thresholds. The historical charts show when performance degraded and correlate it with specific events — a new extract, a spike in users, a server restart.
### Tableau Admin Views
Built into Tableau Server, the Admin Views are dashboards that query the PostgreSQL repository directly. The most useful for performance diagnostics:
**Performance of Views:** Shows the slowest-loading views across the server. The view load time metric captures the full end-to-end time from request to rendered dashboard. A view consistently over 60 seconds is a performance problem at the workbook level. A view that was 10 seconds last month and is now 60 seconds is a performance problem that needs root-cause investigation.
**Stats for Load Times:** Aggregated load time distributions. Use this to identify whether slow performance is isolated to specific workbooks or is systematic across the server.
**Background Task for Extracts:** Extract refresh job history, success/failure rates, and durations. A backgrounder queue that is consistently full — jobs waiting because all backgrounder processes are busy — indicates backgrounder capacity is insufficient for the refresh volume.
### VizQL Server and Backgrounder Process Logs
For specific performance incidents, the VizQL and backgrounder process logs contain detailed timing data. The vizql log includes query-level timing — the time spent in each phase of rendering a view (data source query, mark rendering, JavaScript execution). Parsing these manually is tedious; the Tableau Log Viewer application simplifies it. For systematic analysis, the tabadmin log export and tsm maintenance ziplogs commands provide logs in a form that can be processed with grep or log analysis tools.
Server Configuration Parameters
### Process Allocation
Tableau Server's performance is directly linked to how many processes of each type are running. The default single-server configuration allocates processes based on core count. For servers serving high load, the defaults are rarely optimal.
**VizQL Server processes:** Handle view rendering requests from users. Each VizQL process serves a configurable number of concurrent sessions (default 2 per process). If all VizQL processes are serving sessions at capacity, new requests queue — users see slow load times. Rule of thumb: one VizQL process per 2 CPU cores, with headroom for spikes.
**Backgrounder processes:** Handle extract refreshes and subscriptions. Extract refreshes are CPU-intensive. If extract refresh jobs run slowly or queue, adding backgrounder processes (up to the available core count) improves throughput. Backgrounders should not share cores with VizQL processes — contention between interactive workloads and background jobs degrades both.
**Cache Server and Query Cache:** Tableau's query cache stores the results of data source queries. A warm cache dramatically reduces view load times for frequently accessed content. Ensure the Cache Server process has sufficient memory allocation — the cache is most effective when it does not evict entries prematurely due to memory pressure.
### JVM Heap and Memory Settings
Tableau Server processes run in the JVM. Heap size affects how much data can be held in memory before garbage collection. Under-provisioned heap causes frequent GC pauses that manifest as intermittent slowdowns. For servers with 32GB or more RAM, increasing the JVM heap allocation for VizQL processes typically improves performance.
The specific parameters and their values depend on the Tableau Server version. Refer to the Tableau Server performance tuning documentation for your version — heap settings changed between major versions.
### Concurrent Session Limits
VizQL sessions occupy memory for the duration of the session, even when the user is not actively loading a view. The default session timeout is 240 minutes (4 hours). On a heavily loaded server where users leave tabs open, session accumulation can exhaust memory. Reducing the session timeout to 60–120 minutes reclaims memory more aggressively without impacting the majority of user sessions.
Workbook-Level Performance
Server configuration addresses infrastructure capacity. Workbook-level performance addresses the work the server is asked to do. Many "slow server" problems are actually slow workbook problems — a small number of expensive workbooks consuming disproportionate VizQL resources.
### Identifying Expensive Workbooks
Using the Performance of Views admin view or RMT, identify the workbooks with the highest average load time and the highest total load time (frequency times duration). The highest average load time identifies the worst user experience. The highest total load time identifies the workbooks consuming the most VizQL server resources — the ones that, if optimised, would improve overall server performance most.
### Common Workbook Performance Issues
**Live connections to large databases without row limits:** A workbook connected live to a fact table with 500M rows without partition filters or initial SQL row limits will query the entire table on load. Add a date range filter pushed to the initial load, or migrate to an extract.
**Extract fragmentation:** Extracts that started small and have been incrementally appended for years without defragmentation develop index fragmentation that slows queries. The tableau file format reorganise command defragments extracts. Schedule periodic defragmentation for large extracts.
**Nested LOD expressions:** FIXED LOD expressions on millions of rows require the database (or extract engine) to compute group-by operations at each LOD level. Deeply nested LODs — LODs that reference other LODs — multiply the computation. Where possible, push LOD logic upstream to dbt and join the pre-computed result to the fact table.
**High-mark workbooks:** Workbooks with scatter plots or maps that render tens of thousands of marks are expensive to render in the browser. The rendering time is browser-side (user's machine) not server-side, but VizQL still generates the mark data. Use level-of-detail reduction (aggregated marks, clustering) rather than raw row-level data for dense visualisations.
**Complex table calculations with large partitions:** Window functions with WINDOW_SUM or RUNNING_SUM over large partitions compute in Tableau Desktop after the query returns — not in the database. The computation happens on the VizQL server. Keep table calculation windows scoped to the minimum necessary.
Operational Maintenance
Performance degradation is often not a workbook or configuration problem — it is accumulated operational debt.
### Extract Management
Extracts that are no longer used continue to consume backgrounder resources and storage. A quarterly audit using the Tableau REST API (workbook and datasource list endpoints) identifies extracts with no recent user access. Suspending or deleting unused extract refreshes recovers backgrounder capacity.
Large extracts that can be filtered to a smaller row set should be. A financial analysis extract that only needs the last 3 years of data but contains 10 years is consuming 3x the storage and processing time it should. Extract size directly affects refresh duration and query performance.
### Content Proliferation
Tableau environments accumulate workbooks over time. Workbooks that nobody accesses still consume server resources when referenced by subscriptions or bookmarked by users who have left the organisation. Regular content audits — identifying workbooks with no access in 90 days — keep the content inventory manageable and reduce background noise in performance monitoring.
### Licence and Session Management
Users who leave the organisation but retain active Tableau licences continue to consume licence capacity. Former employee accounts that still have open subscriptions running extract refreshes and email deliveries consume backgrounder cycles. Quarterly licence audits using the Active Users admin view identify licence reclamation opportunities.
Performance Tuning Process
The systematic approach:
1. **Measure:** Deploy RMT or instrument Admin Views before changing anything. Establish current baselines for view load times, backgrounder utilisation, and VizQL session counts.
2. **Identify the bottleneck:** Is VizQL CPU utilisation high (rendering is the constraint)? Is backgrounder consistently full (extract capacity is the constraint)? Are specific workbooks dominating slow-load metrics (workbook optimisation is the constraint)?
3. **Address the primary constraint first:** Process allocation changes affect the entire server. Workbook optimisation affects specific workbooks. Do not add processes if the real problem is a single expensive workbook consuming all of them.
4. **Measure after each change:** Performance tuning without remeasurement does not tell you if a change helped. Change one variable at a time; measure the impact before changing the next.
5. **Establish ongoing monitoring:** Performance problems that go undetected for months before users report them indicate monitoring gaps. RMT alerts on defined thresholds catch degradation early.
Our managed BI services include ongoing Tableau Server performance monitoring and optimisation — contact us to discuss Tableau Server performance for your environment.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →