Thanks for that Diego.
However, as I am looking for some reference to improve Tableau dashboards performance, responses like "there's nothing to see there" or " If so, they need to be fixed and you probably don't want to load test with them" it's not really what I am looking for. If I got stuck with dashboard that takes forever to load it would be awesome to see what really happened and not only focus on errors..
1 of 1 people found this helpful
Sooo....since I'm the progenitor of that thread, I'll chime in.
If you have a dashboard that takes forever to load, TabJolt will tell you (absolutely) nothing that will help you to correct the problem. It'll do nothing more than point out what you probably already know -- which viz is slow.
Perf tuning is not what the tool is meant to do. You're probably wasting your time trying to use it that way.
I JUST finished watching a terrible Halo-related movie on Netflix...so....It's like using a machine gun (forgive the allusion) to snipe someone in Halo. Won't work (unless you get really lucky!). Wrong tool. You really need the beloved SRS99-AM Sniper Rifle (or in Tableau's case, PerformanceRecorder and or a stroll through the logs with the Tableau Log Viewer, "TLV"). In short, you need a microscope, not a jack-hammer.
From a load testing perspective, the only thing you care about from the list above is (maybe) the response time (which is measured BY TabJolt and represents the difference in time between when a request was made and the response comes back...but can be impacted by sleep time settings to the point where the number is not really the truth) and understanding which errors are "real" (typically those in the 500 range) and which are TabJolt getting confused (typically 600 range). The rest is noise.
The events that you are asking about (Init session, bootstrapping, get customized view) are simply part of the standard server rendering process. This stuff isn't documented anywhere, which is why you're having problems finding information on same. Knowing when they start and stop is not meaningful to you. An "Interaction" as defined by TabJolt is a random selection of a categorical filter value on the dashboard. If no categorical filters exist on a viz, then it'll select a mark. Mark selection might or might NOT make the viz do anything extra based on how you designed it.
Back to your problem: Dashboard Performance. I'd suggest you start with Alan Eldridge's white paper, Designing Efficient Workbooks | Tableau Software. It pretty much is "the" resource on making something "slow" fast again.
Hope this helps!
Wow, this is getting crazy now. I've, literally 5 mins before your reply, finished watching your session @ Tableau conference 2014. I am seriously considering getting myself a tinfoil hat..
But getting back to the topic. Thanks for elaborating more about the tabjolt. However, for me, it looks like tabjolt is a dev tool that was mistakenly released to the public as blackbox nobody knows how works.. Well maybe only your main dev, who is locked in the high tower without any free meeting slot till 2032.
I am just looking for an objective tool that will help me understand what is wrong with the dashboards (I can say it's running slow without any tools) and how to solve the problem - whether it's design or server configuration. I was expecting that Performance Recording + Tabjolt would solve the problem but deeper I dig the more problems I find.
I know that in perfect world all vizs should be created according to best practices but in reality, in agile environment, it would be great to know if 80% of time more would improve performance in 20% or more.. And for the example you mentioned - resnponse time: does it include query run time or not? Those are the things that could really make a difference..
Nevertheless, I will take a look at the whitepaper you shared - expect couple of tips there
1 of 1 people found this helpful
Everyone has an opinion, amirite? The tool was orginially built by devs for devs -- internal testing...then was released to the public. SO..you're not too far off the mark.
I'd prefer to see the workbook which is distributed with the "public" version contain about 65% of the vizzes it does now. The KPI & Test Failures reports are awesome. Test Response Time & Test Drill Down tend to just confuse people.All the perfmon-related stuff is good.
Response Time does include query time -- it's pretty much a measure of response time from the client's POV. Query time is not broken out in any way by TabJolt - it would need access to a different set of logs.
You might also find LogShark to be useful - it parses our logs and provides some pretty interesting information on your users' "real world" usage patterns. If you put a little bit more time into it, you can create a PerformanceRecorder-like viz that measures dashboard perceived perf & query execution time across longer periods of time for ALL your vizzes. Example of it's use here: Measuring Tableau Performance against Redshift