Hey Rick -
I'll take a stab at this since no one has gotten to it yet. The golden rule is "if it's slow in Desktop, it's going to be slow in Server".
It's actually is pretty rare to see a workbook that performs well inside Desktop run really poorly in Server. It's normal to get a somewhat slower response from server, but it shouldn't be dramatically different. Most folks end up doing performance tuning/troubleshooting in Desktop, which is much easier.
Can you give me more specifics? What isn't working the way you feel it should?
I appreciate your info. Our clients access Tableau modules via the Tableau server. We have new modules that are 'slow' and we were trying to determine cause(s). We did a time trial for the module that responds the slowest. I have added the results. The test was performed with small to very large data sets (line counts). So, it takes approx 2 times as long to return on the server as on the desktop.
What has your experience been regarding the ratio difference?
Thanks again for your help.
Comparison Refresh Time
Server Desktop diff. Ratio (Server
SKUs (Lines) Contract sec. sec. sec.
1,825 #1 5 2 3 2.5
6,494 #2 8 4 4 2.0
9,276 #3 12 7 5 1.7
14,254 #4 13 10 3 1.3
26,584 #5 31 17 14 1.8
42,008 #6 45 26 19 1.7
The ratio does seem a bit high to me, but part of that could be how you're measuring render time on Server itself.
What version of Tableau Server are you on?
Also, I noticed your SKUs column - What does this mean - Does 42,008 map to 42K rows of data? The fact that some of the "larger" Contacts you're running take a long time in Desktop (10+ seconds) tells me you're either running a heavy query, rendering lots of marks (cells, bars, lines), or both.
What is your data source? Are you using a direct connection or an extract?
After your visualization has run in Desktop, what values are you seeing for Marks, Rows and Columns for a smaller contract vs. a bigger one?
We are on 6.0 and will be upgrading to 7.0 - is there going to be 'better' performance on 7.0?
Data source is direct connection into database. We have tested using an extract but did not see any difference/improvement.
Yes, the 42,008 lines = rows and the report has 2 rows per SKU. The stats are:
Yes. We released version 7.04 just a few days ago and there are performance enhancements that may help you. It still probably won't be as snappy as you want it to be, based on what I see above. however. (and keep in mind, I'm flying by the seat of my pants here).
I suspect that the problem is the number of marks you're plotting. Each mark takes time & memory to render, and I've worked with clients who had to wait minutes for a report to come back when they had 400K-ish marks in a report. It just takes a while to render all those suckers ....and while I have limited experience with this particular flavor of performance issue, I recall it took significantly longer
So, I've got to ask: is there any particular reason why you're showing all that data? Does someone actually browse all 3-82K rows of data?
At the risk of being blunt (sorry!), it sounds like you've just recreated a large-ish Excel worksheet in Tableau. We can certainly carry out that function, but we're going to do better for you as a visualization tool.
That being said, I'd suggest you consider how you can use filters to limit the number of rows you actually display to the user at any given time. Show them a couple hundred SKUs and let them adjust "which couple hundred" using filters.
A technique many Tableau report builders lean on is putting something at the top of a dashboard which allow the report viewer to begin limiting what they're about to look at - for example, a bar chart where each bar is a sub-type of contracts 1-6.
Then, when a user clicks on bar "Contract4.SubType6", we show a limited number of rows beneath the bar chart in a cross-tab format. That'll give you much better performance than just dumping all the rows to begin with.
Also, are you connecting directly to the data source (and what is the datasource) or using Tableau extracts?
Hope this helps?
One other factor that I have not seen mentioned yet is the browser. From what I have read (somewhere in the Forums), IE can take 3x longer to render than Firefox. It might be worthwhile (if your company allows) to try a different browser and re-measure. Just a thought.
Yah - big kudos to Tim for that thought.
His idea made me think of scenarios that look like this:
1. IE slow as a dog
2. Firefox renders same viz faster
3. Chrome renders same viz faster still.
It turned out a TCP/IP setting called "Chimney Offload" was the culprit. When the client disabled the thing, there was a huge increase in speed. For reasons unknown, IE was affected the MOST, but all 3 browsers rendered faster after the setting was disabled on the server.
...note to "everyone else" reading this thread: Don't change this setting just for the heck of it hoping for faster server performance