During the Tableau Conference I took some time out to attend a very odd session: Tableau Like a Sith.
Two masked gentlemen complete with Star Wars style robes explained “evil” ways to use Tableau. The grainy photo below is the only evidence these guys actually exist.
They got into cache warming, and as someone who focuses a bunch on Tableau Server the subject was pretty interesting to me.
Here are the highlights of what was said.
- Cache warming is hard
- Why? Because each viz to be cached must “hit” each VizqlServer process on your server before it’ll be dependably in cache for everyone
- It’s also impossible to force a particular workbook execution to occur on the VizqlServer process of your choice
- Some folks think that using tabcmd export or tabcmd get against a report will cache it.
Wrong. The Application Server process is used for this work, and interactive rendering normally occurs within VizqlServerActually, we changed the way this work, so it is CORRECT in newer versions of 8. - Based on the announcement made during the keynote around a future where the VizqlServer cache is shared, this approach won’t be as relevant moving forward
The quick-and-dirty tool that was shown is pretty simple: It executes any number of reports x times each every y minutes. Doing so gradually gets each workbook “on” all your VizqlServer processes until they are cached across the board. By the way, Interworks has an “industrial strength” solution if you want something dependable and supported by someone.
The following slide was shown to demonstrate what happened when the warmer executed a single dashboard using SQL Server as a data source every 15 minutes. In this case, the Tableau Server was quite small – a single i5 4-core processor. You can see that this box was running 3 different VizqlServer processes – this is overkill. I’d normally run 1 or (max) 2 on a similar box.
“Lord Flashypants” explained that this configuration was chosen on purpose to make across-the-board caching harder to achieve. In addition, he lowered two settings:
• wgserver.session_idle_limit lowered: 240 to 10
• vizqlserver.session.expiry.timeout lowered: 30 to 10
Lowering these setting allowed the sessions created by the “automated user” to be cleaned up more quickly, therefore allowing a new session to be bootstrapped when the user logged in later. When this happens, we hope the new session get created on a different VizqlServer process, therefore warming its cache. I probably wouldn’t do this in the real world. I’d keep these settings at higher values and have the tool execute reports at longer intervals than 15-45 minutes.
He also configured his machine to totally clear the cache every hour-and-a-half.
As you can see, it generally takes a while to get a report cached across all processes. Once that is done, things are fast until the cache is cleared and you start all over again.
You can download this little bit of nastiness here: https://github.com/DarthFlashyPants/sith-cache-warmer
