1 of 1 people found this helpful
A first thought is, how big is your workbook (# of worksheets, # of calculated fields)? I've seen issues with the # of worksheets in a workbook and # of calculated fields (might just be limited to table calcs, I'm not sure) that cause Tableau's performance to decline as either/both of those get larger. There have been a couple of threads on this in the forums in recent months.
The suggestion from Tableau tech support someone shared is to keep workbooks to <30ish worksheets, and to keep the number of calculated fields to a minimum.
When I started working with Tableau last year, I had an "everything plus the kitchen sink" approach to creating data sources and workbooks where I'd have tons of dimensions and measures fields for every conceivable use and leave lots of the "in-between" worksheets coming from developing analyses and views in each workbook, and that lead to intolerable performance. Nowadays I put more effort into tailoring the data sources (for example, to put useful aliases into fact tables that are then pulled into the extract), at times I create more than one Tableau data source on the same data for different analyses, and I'm pretty rigorous about cleaning up unused calcs and worksheets, or creating multiple workbooks.
My impression is that the performance decline from # of worksheets/# of calcs is not a straight line, but a curve with a steeper drop-off. Two warning signs that you are getting close are when the response time for adding an alias goes from an instant click to taking a couple of seconds, and another is when the recalculating the view dialog shows up after saving a calculated field (even one that's not in the view).
Thanks for sharing your thoughts/experiences, Jonathan.
In my experience the performance degradation is not a straight line, but rather a steep drop off just as your impression.
My workbook is currently fairly modest, in my opinion, in terms of # of worksheets (23 worksheets which includes 4 dashboards), though obviously if Tableau tech support recommends <30ish worksheets, then I am closely approaching their recommended limit on this... which to my way of thinking seems to be a fairly significant limitation for developers--unfortunately. Regarding, the # of calculated fields... more than likely I am pushing the limits on this. I am not sure exactly how many I have, without going through and manually counting the number of dimensions/measures that are prefixed by "=" (is there any easy way to get a count of your dimensions/measures and also a way to easily identify which ones are not being used so that I can delete them), but I would guestimate that it is around the ~250 count---alot of ratios with most being used, which probably is far exceeding the Tableau tech support recommendation to keep these at a "minimum", which as most would agree, is not very useful of a recommendation. IMHO, I regard both of these as significant limitations for the development environment and definitely throws a "monkey wrench" into my plans for modest "build out" going forward.
It doesn't make sense to me that editing an alias would incur such a performance "hit". There must be something going on behind the scenes that is unnecessary or inefficient or simply something that I don't understand.
Anyways, your recommendation about creating multiple workbooks would not work for me without a fairly robust redesign of the functionality of my dashboards since I use actions *across* dashboards. I could potentially go through and find some unused table calcs but I am not sure that I would find that many to really solve the problem...especially since I would like to be creating more. I maybe able to create a few calculated fields outside of Tableau prior to connecting.
I wish I understood a little more about what Tableau is doing behind the scenes and also about other limitations I might encounter to know how to proceed. And hopefully these performance issues, and development limitations might be something that Tableau can address in a future release.
So here is what I accomplished in ~30 mins of development (clock) time:
1. Updated my SQL connection by modifying my custom SQL to add 4 table elements
2. Refreshed TDE (only ~2mb)
this only took about 2mins including a "preview" of my data
3. using 4 existing calculated fields as "templates", I created 4 new calculated fields by:
a. Duplicate (right click) -- took 1-2 mins each time
b. Edit (right click) -- pretty quick to pull up dialogue and edit appropriately, but took ~1-2 mins to show up as new measure
c. added new measure to a simple table for validation -- real quick response to do this and update viz
d. Edit Alias (right click on measure in viz) -- real quick response to get dialogue, but refreshing took 1-2 mins
So adding a single measure to my workbook took 6-7 mins... for all 4 measures it was on the order of 25-30 mins (I have the log to get exact times)---which is crazy. The majority of the time was interacting with Tableau's equivalent of metadata, not refreshing a viz. In all of these cases, Windows Task Manager shows the CPU usage maxing out. Windows CPU usage is maxing out when I wouldn't expect it to be necessary... ????
Randy, any way you could open up a support case on this if you can repro the issue consistently? This probably needs to be bugged - especially if we can get dev a sample that they can debug with....
~250 calculations is definitely into the "too many for Tableau's performance" range, unfortunately.
I submitted an issue on this several months ago, I'll dig up the reference on Monday. I'm pretty sure it still exists, since a workbook I was building views for on Friday is in the middle of its performance dive.
Russell: I would be happy to open up a support case... though unfortunately I will not be able to provide a sample since I am working with confidential financial data. I would need the TDE to be flushed of its contents and I don't have any tools to actually accomplish this. If you have any ideas... Would getting the "log" help at all?---this I could provide.
Jonathan: If you have something that would give Russell and his team something to work with, maybe this would suffice to get the dev team looking into this performance issue.
Hey Randy -
If Jonathan's workbook is displaying more-or-less the same behavior, we're probably good. No need for you to go through the extra work