What version of IE?
Assuming you're running a supported version, there should be only very minor performance differences between browsers - you might want to open up a support case.
A few customers have run into the issue detailed in the links below - and for reasons unknown it's particularly ugly when the browser is IE. (Note that this is an operating system setting that impacts Tableau Server and not a Tableau Server issue itself)
Hope this helps!
Sorry to hear you are having problems. Answering a couple of questions will help guide some answers:
a) a problem with a new workbook, so it has never worked correctly or
b) a new problem with a scenario that used to work just fine
Were there any recent changes to your system that might point toward a culprit? Tableau upgrade? IE patch? OS update? etc....
HI. Thanks for response. We're able to recreate with IE 7, 8 and 9. It slows down the more we navigate between views. Same problems don't exist if we use chrome. Isolated to IE.
We've had the issues from the beginning with IE. Works fine with Chrome. It seems to be related to the issues IE has with Java. Working in Chrome and IE side by side the views fly in Chrome and become unusable in IE. We've monitored the server processing and it's not a server side issue. Using Chrome frame in IE helps a lot but users still experience issues.
Would the issues described in this article only affect IE? Sites and speed is perfect on Chrome and other browsers. Issue seems to be isolated to IE. We've been able to replicate very consistently for a lot of users. When the same users hop on Chrome or other browsers the issues go away. Everything I've reads seems to isolate it to known problems with the internal engine for for IE processes Java. I don't think these issues have been resolved in IE 8 or 9.
Based on what you'e described, we know this so far:
- The workbook itself is "OK" - it renders well enough in Chrome and FF
- The Tableau Server also seems "OK".
The slow rendering behavior described in the links I offered impacted all browsers for the (few) customers where these settings were the problem - but the impact was much more noticeable in IE. Why? I honestly don't know.
And as you've said, IE is a very popular browser -- nearly all of our customers use it against Tableau Server without any problems. Safely ruling out some sort of "universal" problem with IE (which Tableau would know about by now), it sounds like something is different in your environment. Nailing this down is something that product support can help you with.
If you don't want to get support involved quite yet, here are some other things you could try and/or investigate. Take all of this with a grain of salt, as I'm not a support guy myself
- Make sure you are on the latest/greatest release of Tableau Server, which is 7.013
- Do you see the same behavior against your backup / test / dev Tableau Server?
Hope this helps a little, and would love to know how this turns out.
The default setting internally is the run intranet sites in compatibility mode. Not sure if this will make a difference but I will test with a user that's getting very slow performance on IE7 and see if that makes a difference. They are getting great results with Chrome so it will be very obvious whether it's working better in IE afte rthe setting is changed'.
The one question I would have about other customers is whether they are consistently using multiple views in the same workbooks. We have a lot of linking views in one workbook and it it fine when using a single view but as they click to and from different views in the same workbook IE just gets slower and slower unitl it's too slow to use. Same issue doesn't happen in Chrome or other browsers. We can re-produce almost every time in IE and many different machines. Same users have no problem with Chrome. I'll try the compat setting and see if we get lucky. I'm also trying to determine if the users install of chrome frame is actually being used as the render engine when they go to the sites. It's installed but not sure if it's actually being used to render. If it's a java issue in IE then chrome frame should help speed up the processing a lot.
Most of our customers use multiple views and many jump around quite a bit, as you describe.
Something else you could try that might be interesting - find a sample workbook out on our solutions or visual gallery pages with multiple tabs and click around a bit to see if the same behavior occurs. Or, go one better and actually publish one of your workbooks to Tableau Public and test it there.
This won't be an applies-to-apples comparison, of course but it could get you closer. ****, I'm happy to throw up one of your workbooks on my personal server that's accessible via the internet.
David, Russell, was the issue resolved?
We are having a similar problem. I have monitored the Windows task manager on the client side and have noticed that action filters on a dashboard increase the memory used by iexplorer. For example, after initially loading the dashboard the memory reads ~140MB. After clicking an action filter, the memory usage goes up (say to 180MB). Then when I clear the action filter, the memory stays the same. If I then perform another action filter, the memory usage goes up again (say to 220MB). I can do this indefinitely and get the memory usage of iexplorer over 1GB.
This phenomenon does not occur when using Firefox.
Nicholas -I *think* there's a bug open on this, but it would be wise for you to open up your own support ticket just in case your problem is different and/or to add more weight to the original bug.If I were you, I'd reference this thread when you open your case. Include a concise list of steps that will reproduce the issue (sort of like what you started in your question). If your server happens to be externally facing, it would also be great if you could allow our support professional to hit your viz directly....Good luck!
FYI in case anyone else reads this thread.
Please download and install Server 8.0.2. There is a fix around memory leaks in IE 8.0 (and to a certain extent, IE 9) that should help you out.
Currently forced to use IE8 (it's killing me!) but the company will be go to IE10 this year. In the mean time this is good news. Thanks for keeping up with this, Russell