Tableau Dashboard Performance.

Sunday, August 26, 2018

Tags: tableau, performance, tabjolt, load test, research

When you start complex dashboards for bigger scale of audience, there are some issues you need to be careful in terms of delivering a high performance dashboard on Tableau.

How to get best performance out of Tableau Dashboards?

In order to get best performance out of the dashboards built in, there are few factors to take into consideration. In fact, I had a previous study on how Tableau behaves on certain scenarios. I will first share this, then I will try to make bullet points for the certain aspects that we must be careful with.

Tableau Dashboard Load Test Results

This test was completed on Tableau Server 2018.1 on Azure Windows Server with 2.39GHz x 4 core and 16GB memory. For the load test, TabJolt was used for 4 scenarios: (1) Single User for 2 minutes, (2) 10 concurrent users for 2 minutes, (3) 50 concurrent users for 2 minutes, and (4) 120 concurrent users for 2 minutes. For each test and scenario, Tableau Server was restarted and the dashboard was initially loaded to be cached.

To see the full report please visit the link below, I also embed the dashboard here so you can play around:
Tableau Load Test Results on Tableau Public

Overall, performance basically relies on the number of marks (granularity of the report / how detailed with lists) and the number of calculations you built on the dashbaord.

Dashboard sizing (making it fixed sized or automatic) makes little to no impact. But for high concurrency fixed sized dashboards provide around 1 second of better load times. (Comparing Test #1.x vs #2.x)

Number of Marks (Granularity) makes quite a lot of impact. Same dashboard with 18 marks (bar graph) runs 2 times faster than the one with 8585 marks (text/list report). (Comapring Test #2.x vs #3.x)

Maps can also cause some performance issues due to the time passed to connect to map services on Tableau. MapBox map services can run faster comparing to Tableau Map Services but this is solely network issue. I witnessed terrible result with maps just because company's firewall and network policies were making it so difficult to communicate with the map services. (Comparing Test #8.x vs #9.x)

Connection types play crucial part when you use live connection instead of hyper extracts. Otherwise it does not matter if you connect to a text file or relation database. However, complexity of your query and how well your database handles the query executions can be very very important. And if you use extracts you gain around 70% better performance. In this scenario, it will all depend on your Tableau Server configuration. (Comparing Test #2.x, #14.x, #15.x, #16.x)

Number of Sheets within the dashboard is also important. It makes almost no difference until after 4+, it will start getting slower. It is still not so vital but it gets very performance consuming after 8+ sheets. (Comparing Test #16.x, #17.x, #18.x)

Dashboard Actions make almost no impact on the performance. (Comparing Test #18.x vs #19.x)

Dashboard Filters, on the other hand, can vary the performance as Tableau will try to fill out those filter values (Comparing Test #18.x vs #20.x)

Using Images can be problematic if the size of the images start exceeding certain size. To be able to see the impact, we used single image with 1MB in size and 100MB in size. We had many problems with response times with that huge image file especially with high concurrency. So the size of the images is very important. (Comparing Test #21.x, #22.x, #23.x)

Number of Dashboards within workbook will affect the performance by the same reason that the number of views will be increased. (Comparing Test #22.x, #24.x, #25.x)

And number of calculated fields, this is very important as this affects the CPU time directly and you will not save any by adding lots of RAM on the server. 1 single calculated field affects the performance by slowing it down 10 times even it is not used on any one of the views. So calculated fields should be added up into extracts or your source data as much as possible. (Comparing Test #25.x, #26.x, #27.x, #28.x)

Also Analytical functions like trends and forecast can be considered yet they have no visible impact on the performance. (Comparing Test #28.x vs #29.x

Points to Watch Out for Performance

  • When using images make sure its size is enough for screening.
  • When using images, try adding the image from the image object rather than using extra worksheets unless you will use it as a button with dashboard action. And good news, they have added "button" object as of version 2018.2 along with "extension" object.
  • If you will place a text, use with the "text" object rather than using sheets. You can still embed parameter values in text object to create dynamic views.
  • Try to embed all calculated fields into datasource extract. This will not happen, of course, if you are using another field from a blended datasource. But everything within the datasource should be in the extract.



© 2018 - DJames.net