Is there a chance that you're using
data blending on your dashboard?
If so, please read this insightfull comments
by Jonathan Drummey on blending performance:
Hope it may help.
No, not using Data blending.
Moreover, as I have continued to try and isolate the issue, I have removed all other joined tables from the equation. So, now I have only one six field table, which works as expected from within desktop and I am able to work with the same table from within SQL Server without issue. However, when I publish the worksheet to server, it take as much as 8 minutes to render the page, but it does eventually render the page without triggering an error of some sort.
It is comprised of two pills on the row shelf and one in the "Text" container.
Any other Ideas?
Does the workbook has an excel based extract? The reason i ask is, i encountered an issue few months ago, while trying to create a excel extract based workbook on desktop which takes about few seconds to open but when published to server takes about few minutes or so. I was able to identify the issue.
- If no text/excel sources are involved, i'd check the connectivity between the tableau server and the database server.
- Any network issues between the source and server?
Could you post the what kind of Datasource used in the workbook?
The obvious next step is
to record performance
Of this dashboard
on the server.
Find the bottleneck.
Compare to desktop.
No excel/text extract component. the datasource is a single table in MS SQL database and I tried using a live connection and an extract - neither improved the situation.
Can you please tel me how many sheets you have used in dashboard and when you extracted data, did u hide all unused icons.Please upload workbook.
It looks like your Tableau Server
is having difficulty when connecting
to your MS SQL Server. Reasons are:
-- Tableau Server machine is "far" from SQL Server machine.
By "far" I mean network topology distance and permissions.
Please check your network admin to figure out.
-- There should be latest compatible version
of ODBC drivers for your version of MS SQL Server
installed on the Tableau Server machine. Those ones
referenced on the Tableau "Drivers & Activation" webpage
should work smoothly.
I had anecdotal case when a customer of mine
installed the proper drivers on their desktops,
but failed to do the same on their servers :-)
The behaviour was very similar to yours.
And last but not least:
What is the hardware configuration
of your Tableau Server instance?
Hey Robert -
From what I can see, no one suggested running a Performance Recorder report against this sucker to get some hard, cold performande data. You should do that. Use these help topics to do so:
I'd suggest that you run this process right after stopping/restarting Tableau server to make sure nothing is in cache - this could skew results. You could also manually kill the vizqlserver processes running on the machine first (they will immediately re-spawn, but without any cache).
The first thing that comes to mind is the number of rows you're rendering - realistically, no human being is going to read / browse 60K+ rows of data, so this viz isn't overly useful unless you're doing something that Tableau isn't really made to (act as a data-dumping mechanism).
In your shoes, I'd try the following to narrow down the issue:
- Add a filter to so that only a couple hundred rows are returned. How fast is Server now (it'll generally never be as fast as Desktop because of of all the Web Server "stuff" on top of the rendering process)
- Run the same report under Desktop and make a Performance Recorder report there to (again, make sure you don't run the report on it's own BEFORE you turn the performance recorder on and execute the viz - you'll skew your results and make it look faster than it is).
What sort of hardware is this server running? What about the machine on which Desktop is running?
Thanks for your suggestions. At the request of Tableau Support, I did make a performance recording and forwarded it to them. Looking at the visual it created, I did not notice anything out of the usual.
In order to isolate the problem, I created a worksheet using this one table with 60K records. In my operational use of the table the records are filtered by a dashboard action filter that displays typically less than 100 rows. I am convinced that this problem has nothing to do with the number of records in the table, because I can reproduce the error in tables that are smaller in size. The common factor, as I mentioned earlier, is the use of multi-word fields (i.e. sentences and paragraphs).
Using a table of 60K rows, without a field of that type loads in seconds (desktop and server). With a multi-word field included, it loads in seconds on desktop, but takes 8 minutes on Server.
Thanks for the additional suggestions. I am using the latest drivers and my distance from SQL Server is not an issue (a couple offices away on the same floor. Moreover, this problem has been isolated to tables that have fields that contain multi-word inputs (i.e. sentences and paragraphs). All other visuals on Server are working well - I don't believe this would be the case if it were network or driver related.
Vikram, what was your solution? I think I'm having the exact issue you're having.