Using a “Hidden” Sheet for Advanced Action Filtering

Learning to design so that you limit loading unnecessary rows of granular data is the most important technique you can learn to make Tableau perform well. It reduces the strain on the database in finding and returning data, and it limits the amount that Tableau needs to return. Ask yourself: “Am I getting tired of scrolling through this list trying to find what I need?” If the answer is yes, consider what other views of the data might help you filter down just to the rows you need to see.

Setting Actions to Exclude when nothing is selected

The ideal workflow in Tableau, both from a performance and a visual analysis perspective, is useful visualizations that filter via Dashboard Actions that act on click / select. You can limit what is shown by setting your Actions to Exclude when nothing is selected. After the first time you do a selection and clear it, the affected sheets won’t show anything until something has been selected.


Thoughts on MPP databases and Tableau

As the recent post on Vertica brings to light, sometimes really highly performing systems need a little configuration to perform optimally with Tableau. There’s a particular set of systems that require some extra thought and care to use with Tableau, because if you set off without any planning and expect to combine Tableau’s ease of use with the speed of these systems and end up staring at the “query executing” screen for 10 minutes, you may start to doubt everyone’s claims.

The systems I’m talking about are the Massive Parallel Processing (MPP) databases. There’s already a great explanation of them here so I’m not going to go too deeply into how they work, other than what is relevant for Tableau. Which systems that Tableau supports are MPP (don’t get too angry if I get this a bit wrong) (in no particular order):

  • Teradata
  • Vertica
  • Redshift
  • Neteeza
  • Greenplum
  • Aster (although there is some Hadoop going on in the backend)
  • ParAccel


Identifying Tableau query performance issues through the log files

There are some good reasons to look at the actual queries Tableau sends to a live relational database:

  1. Performance is not good and your DBA needs to know what is happening so they can optimize. This goes for live connections and slow extract generation.
  2. Your viz still isn’t performing well enough even with extracts, but you don’t understand the TQL language you see in the Performance Recorder (it’s okay, no one does!). Seeing the same logic in SQL can help you understand what exactly is going on
  3. You just want to marvel at the amazing ability of the VizQL engine to translate your actions into SQL. You should check out what LOD calculations,  Sets, or calculated fields look like sometime just to marvel at what is going on

Read more for how to accomplish #1


Monitoring Windows System Performance in Tableau 9.0+

Update: You might just skip all this and go with the newly released TabMon to bring together all your Tableau Server system performance needs.

There’s a great Tableau KB article on using the Windows Performance Monitor (perfmon) that unfortunately hasn’t been updated since the 9.0 release. The steps in perfmon are all the same, but there are few more processes to monitor than there were in the 8.0 series

  • Vizqlserver – processes that query data and build views
  • Vizportal – The Tableau Server UI that is not a viz (shouldn’t be used much in an embedded situation)
  • Wgserver – Now just the REST API server (and a few other tasks in)
  • Backgrounder – takes on long running tasks like extract refreshes
  • TDEServer64 – The Tableau Data Engine (TDE), our fast columnar data extract engine
  • Searchserver – the SOLR service Tableau runs
  • Zookeeper – Tableau coordination Services
  • Redis-server – Shared cache services
  • Httpd – The Apache web host and load balancer, usually a very low user of memory, but worth watching
  • Dataserver

For how to analyze it all, nothing beats the Alan ‘Ty Alevizos’ Smithee’s original workbook and instructions .