So there are so many factors that could be affecting this. Any Desktop/design things, I should be able to help & a bit on the server performance side...but may need to ping in a server expert on things like "Number of Cache servers"/"Backgrounder Load"...etc.).
So first things first...how many rows of data do you have, and does it work well (i.e. fast) on desktop?...this will help isolate if the issue is the dashboard itself, or the server (eg. backgrounder tasks hog all the resource, so if the server is doing some extract rebuilds, for example, it will be relatively slow during those periods).
Loading time on dashboard is fast when compared to server.
I have separately created that dashboard and published in server - That's is also working fast. But when it comes to storyboard its killing me. More than 2 min of time.
that is odd...I wasn't aware that Storyboards were doing anything other than rendering the dashboard (they are showing) but with some pre-saved filtering/actions). I must admit, we've not really used storyboards on server, so don't have any experience of how they perform (relative to the dashboards they are built with)
Just so I'm 100% clear;
Full workbook, with Dashboards & Storyboard (built from some of these dashboards) runs fast on Desktop (including the storyboards).
Full workbook, with Dashboards (but storyboards removed) runs fast on Server (including the dashboards that run slow when shown in storyboards).
Full workbook, with Dashboards & Storyboard (built from some of these dashboards) runs slow on server (but only the storyboards run slow). So the dashboards, from which the storyboards are created run fast when used as dashboards.
If you can confirm the above, I'll have a think/play (...ping someone smarter!!) and let you know if I find anything
I am gonna remove some useless sources. Will this help?
It certainly can't hurt!...If there are unused datasources in the workbook, it will take up unnecessary storage-space...but from my (admittedly limited) knowledge of the 'under the bonnet' workings, I'd have thought Tableau only loads into the RAM the data it needs to render the Viz. I have a workbook with 2 datasources, one very fine grained (120M+ rows), and another which is an aggregated version (3M rows). On my dashboards, most are built from the 3M rows (aggregated) data-source, and it's only when the user clicks to see the 'fine detail', they are switched to the 120M row source dashboard. In my experience it only starts getting slow, when the user clicks to the fine detail, version (and this is expected with the size/complexity of that datasource). So appears that the fact there is a 3M and a 120M+ datasource, has no affect on the speed, until the 120M one is needed. And especially as it works fine on desktop (and those troublesome dashboards only perform poorly when used in a storyboard, and then only on server)...so can't see it would have a huge impact.
The bit I'm still confused about, is a storyboard (which contains a single sheet/dashboard, with some pre-filtering) running differently (or markedly different) from when that dashboard is used, outside of a storyboard...I've no knowledge of this, but assumed (maybe incorrectly) that a storyboard would just be the dashboard, with some Chrome around (title, storyboard text), and some memory of the filtering/actions it needs to apply. Speaking of which...it's not that the forecast dashboards (as a dashboard) have a filter on (say to last day), but the storyboard version has this removed, so it trying to render much more data? (...although that wouldn't explain why it's faster on desktop!!)
If it was running slow on desktop and server, then I'd suggest looking at the build (context filters, number of calcs, 'relevant value' filters, calcs used...etc.)
If it was running fast on desktop, but slow on server, then I'd suggest looking at the server load and spec
...but this one is neither! The 'forecast' dashboards run fine on desktop and server, unless they are put into a storyboard, when they only run slow on server. I've had a hunt around, and can't find any other problems with storyboards and speed (but they probably aren't used, relative to dashboards/sheets, as much on server). We use storyboards for presenting back, and sharing findings back to the client (via desktop)...but the models we provide to our clients on server, are just dashboards.
Our dev server is turned off over the weekend (and bank holiday in the UK on Monday)...but I'll do some experiments next week, and see if by putting existing dashboards we have, onto a story it changes the load speed.
Just checked the performance of dashboards. Found that Dashboards are taking more than a minute time to load. Hope problem lies here. Please help
Please go through the below links in order to understand and increase the Performance at Tableau end.
Excellent (in terms of where the problem lies!)...that makes a lot more sense. So the resources that Sudhakar has suggested are all ones I'd have pointed you to...but I'll also go through a few extra bits.
Is your data extracted to a TDE? if so have you 'Optimized' the TDE? if not on TDE and is LIVE (say against SQL server) what database are you using (depending on the answers to these I'll may have some further questions)
If you are use an fast-database (eg. EXASol), or a TDE, and has been 'Optimized'...the next port of call is the 'Performance Recorder'...
- Open up your workbook, but ensure you don't 'click' on the worksheet you want to test (Tableau is very clever at caching, so you don't want to performance assess the cache!)
- Start Performance Recorder (Help -> Settings and Performance -> Start Performance Recorder)
- Click on (Open) the offending dashboard and let it load
- Stop Performance Recorder
This will no open up a Tableau workbook, showing the queries and execution time for all the elements of the dashboard loading...from here you can then see if it's a single element (eg. a calculated field) or multiple elements (or just the sheer number of sheets feeding the dash/ lots of 'relevant values only' filters...etc.)
Once we have this we can then look at ways (say if it was a single calculation) to make that calculation faster. It's not always possible, sometimes what you are asking is just very big/complicated and so you'll have to live with the performance, but 9 times out of 10 I generally find a bit of saving's somewhere.
Hope that helps, and interested to know what you find (happy for you to share the performance recording workbook here, if you want me to take a look)
Thanks to all. I found its speeding up after removing a field from report.