How Many VizQL Processes in Tableau Server?

Trying to figure out the right number of VizQL processes for your Tableau Server can feel like a tricky balancing act. Set too few, and your users will complain about slow-loading dashboards. Set too many, and you might overwhelm your server's memory and CPU, causing everything to grind to a halt. This guide will walk you through exactly what VizQL processes do, how to determine the right number for your server, and how to configure them properly.

Graphed

Build AI Agents for Marketing

Build virtual employees that run your go to market. Connect your data sources, deploy autonomous agents, and grow your company.

Build Your First Agent

What is a VizQL Server Process, Exactly?

Think of the VizQL Server process as the heart of Tableau Server's ability to show you visualizations. When a user opens a view or a dashboard in their web browser, the request is sent to Tableau Server. A VizQL Server process is what picks up that request, runs the necessary queries against your data source, and then renders the visualization - the "viz" - which is sent back to the user's browser.

Each interaction a user has with a dashboard, like changing a filter, hovering over a data point to see a tooltip, or sorting a chart, triggers the VizQL process. In essence, it's the engine that handles user sessions and turns data into the interactive dashboards your team relies on.

One critical thing to understand is that a single VizQL Server process is single-threaded. This means it can only handle one primary task for one user at a time. If you have five users all trying to load complex dashboards simultaneously but only have two VizQL processes, three of those users are going to be waiting in a queue. This is precisely why setting the right number is so important for performance.

AI Agents for Marketing

Crash Course

Graphed

Free PDF · the crash course

AI Agents for Marketing Crash Course

Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.

Download the PDF

Why the Number of VizQL Processes Is a Big Deal

The number of VizQL processes you configure directly impacts two critical areas: user experience and server resource utilization. It's a classic trade-off between concurrency and stability.

• User Experience and Concurrency: The more VizQL processes you have, the more concurrent users you can support smoothly. Each process can manage a user session, so doubling your processes roughly doubles the number of people who can actively interact with dashboards at the same time without waiting. If users report that dashboards are taking a long time to load, especially during peak business hours, an insufficient number of VizQL processes is a common culprit.
• Server Resource Utilization (RAM and CPU): On the other hand, each VizQL process is a significant consumer of server resources, particularly RAM. A single VizQL process can easily consume several gigabytes of memory, especially when rendering a complex dashboard with a large dataset. If you provision too many processes for your available hardware, you risk "resource contention," where processes fight over limited RAM and CPU cycles. This can lead to the server becoming slow for everyone, and in worst-case scenarios, processes can fail, leading to errors for your users.

Finding the sweet spot is key. You want to allocate just enough processes to handle your peak user load without starving the server of the resources it needs to operate other essential background tasks.

Key Factors for Correctly Sizing Your VizQL Processes

Unfortunately, there is no magic number that works for every organization. The ideal configuration depends entirely on your specific environment. When determining how many processes you need, you should consider four main factors.

1. Number of Concurrent Users

This is the most important factor. You need a realistic estimate of the maximum number of users who will be actively using dashboards at the same time. This isn't your total number of licensed users, it's the number logged in and clicking during your busiest time of day (e.g., Monday at 9 AM when everyone checks their sales dashboards).

If you're unsure, check the "Stats for Load Times" administrative view within Tableau Server to identify your peak usage hours and the number of active users during those times.

2. User Behavior and Interaction Patterns

The way users interact with dashboards heavily influences the load on VizQL. Consider two different user types:

• Passive Viewers: These users log in, open a single executive KPI dashboard, look at the numbers, and log out. Their session is short and puts a very light load on the VizQL process.
• Active Analysts: These users open a complex dashboard and spend 30 minutes drilling down, changing filters, exporting data, and pivoting the analysis. Each action keeps their session's VizQL process busy for a longer duration.

If your user base is mostly passive viewers, you can support more concurrent sessions per process. If you have a lot of active analysts, you'll need more processes to handle the sustained load and ensure a responsive experience.

Graphed

Build AI Agents for Marketing

Build virtual employees that run your go to market. Connect your data sources, deploy autonomous agents, and grow your company.

Build Your First Agent

3. Dashboard Complexity

Not all dashboards are created equal. The complexity of your vizzes directly correlates to the RAM and CPU a VizQL process will need.

• Simple Dashboards: A few bar charts and scorecards pulling from a clean, aggregated data source. These render quickly and are light on resources.
• Complex Dashboards: Dozens of worksheets, intricate Level of Detail (LOD) calculations, large, unaggregated data sources, data blending, and heavy use of filters. These dashboards require the VizQL process to do a lot more work, consuming more memory and CPU time for every render and interaction.

If your most popular dashboards are complex, you should be more conservative with the number of processes you add to avoid overloading your server's memory.

4. Server Hardware Specifications

Your server's hardware provides the ultimate ceiling on how many processes you can run effectively. The two most important specifications are:

• Physical CPU Cores: This is a primary driver for Tableau Server's process allocation rules. Don't look at logical cores (hyper-threading), focus on the physical cores available.
• Available RAM: This is often the most critical limiting factor. Each VizQL process needs a significant chunk of RAM. If sessions start failing with memory-related errors, you likely have too many processes for your available RAM. As a general rule, a server node running VizQL processes should have at least 64 GB of RAM, with 128 GB or more being common in enterprise environments.

Sizing Formulas and General Recommendations

Once you've considered the factors above, you can start with a general formula as a baseline and then adjust based on performance monitoring.

For a dedicated node running Tableau Server, a common starting point recommended by consultants is:

Initial Number of VizQL processes = Total Physical Cores / 2

For example, on a machine with 16 physical cores, you would start with 8 VizQL processes. This is just a starting point. From there, you can use these guidelines to adjust:

• For Interaction-Heavy Environments: If you have mostly active analysts using complex dashboards, you might need to increase this to be closer to Number of Physical Cores. For a 16-core machine, you might test with 12 or even 16 processes, provided you have sufficient RAM (think 128GB+).
• For View-Heavy Environments: If your users are mostly passive viewers looking at simple dashboards, the starting point of Cores / 2 or even Cores / 4 might be sufficient.

The most important advice: Start with a conservative estimate, run load tests (if possible), and closely monitor server performance during peak hours. Gradually increase the process count by one or two at a time and observe the impact before making further changes.

AI Agents for Marketing

Crash Course

Graphed

Free PDF · the crash course

AI Agents for Marketing Crash Course

Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.

Download the PDF

How to Configure VizQL Processes in Tableau Server Manifold (TSM)

Altering the process count is a straightforward task using the Tableau Server Manifold (TSM), which can be accessed through a web interface or a command-line interface (CLI).

Before you begin: Any change to topology will require you to apply the changes and restart Tableau Server, which will cause a service outage. Plan this change during a maintenance window.

Using the TSM Web UI

1. Navigate to your TSM URL in a browser. It is typically https://<your-server-name>:8850.
2. Log in with your TSM administrator credentials.
3. Click on the Configuration tab.
4. You will see a diagram of your server topology. Click on the VizQL Server process.
5. On the right side of the screen, you can adjust the number of processes for that node. Use the plus (+) and minus (-) buttons to set your desired count.
6. After setting the number, a banner will appear at the top. Click Review and Deploy Changes (or similar wording based on your version).
7. Carefully review the pending changes and click Deploy and Restart to apply them. The server will now restart, which may take several minutes.

Using the TSM Command Line (CLI)

1. Open a Command Prompt (Windows) or Terminal (Linux) on the Tableau Server machine (or a machine where you have TSM installed).
2. Use the following command to set the number of processes. You need to know the node name (for a single-server installation, it's usually node1).
3. You now have pending changes. To see them, you can type:
4. To apply the changes and restart the server, run:

How to Know if You Got It Right: Monitoring Performance

After adjusting your VizQL process count, you must monitor the server to see if your change had the desired effect. Don't just set it and forget it.

• Administrative Views: Spend time in the built-in Tableau Server Administrative Views. Specifically, look at "Performance of Views." Are load times improving or getting worse? Look at the "Stats for Load Times" view to see if you have long wait times, which are shown as "Number of Queued Requests." If this number is frequently high during peak hours, you may still need more processes.
• Server Process Status: In the Tableau Server Status page, you can see the real-time status of each VizQL process. If all your VizQL processes are consistently "Busy," it’s a strong indicator that you are capacity-constrained and should consider adding more. In a well-sized environment, you should see a mix of "Busy" and "Idle" processes during the day.
• System Resource Monitoring: Use Windows Performance Monitor or Linux command-line tools (like top or htop) to watch CPU and RAM utilization on the server. If your RAM usage is consistently over 90% or your CPU is pegged at 100%, you may have provisioned too many processes, and the machine is struggling to keep up. In this case, you should reduce the count.

Tuning your server is an iterative process. Monitor, adjust, and monitor again until you find the perfect balance for your unique workload and user base.

Final Thoughts

Configuring the right number of VizQL processes is a critical step in optimizing your Tableau Server for a great user experience. By understanding what these processes do and balancing user concurrency against your hardware's limits, you can create a stable, responsive, and efficient analytics environment for your entire team.

While fine-tuning enterprise BI tools like Tableau is a detailed process, getting straightforward insights from your other business platforms shouldn't require this much configuration. Sometimes, your marketing and sales teams just need quick answers without waiting on an analytics team. With AI-powered tools, we created Graphed to connect all your data sources and allow anyone on your team to create dashboards and reports simply by asking questions in plain English.