Tableau Love

tl;dr: Tableau Server’s Refresh Less Often setting means 12 hours.

The details

Tableau Server help has the following to say about Refresh Less Often:

Refresh Less Often—Data is cached and reused whenever it is available regardless of when it was added to the cache. This option minimizes the number of queries sent to the database. Select this option when data is not changing frequently. Refreshing less often may improve performance.

And a KB article on the subject says:

When Refresh less often is selected, the cache has no expiration date. VizQL will continue to use the cache until the view is manually refreshed or until Tableau Server is restarted.

Once upon a time, this info was 100% correct. Now it’s a little bit more nuanced. When Tableau 9 and the external query cache came along, I read some internal docs that mentioned that the new “upper limit” would be 12 hours instead of “Forever, except for process failure / bouncing”.

A year or so later there have been some questions on this setting again and opinions between colleagues at Tableau are mixed – some thought it was still “forever”, some thought it was 12 Hours.  At one point someone was actually going to search through the code to get a definitive answer, but we never got around to it.

Anyway, saw this question on the forums again a few days ago and got annoyed with myself. Decided to test this once and for all.

So, I tried two tests:

The simple One

When I got up a couple days ago, I immediately bounced my server, then executed a long running viz that hits Redshift. It’s really easy to tell when this sucker is cached because the uncached version can run for upwards of 30 seconds.

I then went to work, intending to re-run the viz 12 hours later when I got home. When I arrived back at the crib I had a beer with my Sweetie, we went out to eat, and I promptly forgot. Go figure.

The next morning (maybe 22-23 hours later) I remembered, hit the viz, and found it was not in the cache.

The Real One

Through the magic of re-setting my machine’s system clock over and over again, I did the following:

~9:20a: Executed two vizzes: My long running Redshift dashboard (30s) and a long-running extract-driven viz (10s). I signed out of Tableau and drank some coffee. It was good coffee.

~10:30a: I set my clock ahead an hour and hung around for a while. You can see my logs registering the change in time:

Next, I logged in and hit those vizzes. They rendered immediately. Clearly hitting the cache. I used jconsole to interrogate vizql’s jmx MBEANS and it looks like I had a hit on the (new! improved!) 10.1 bootstrap cache and maybe took advantage of shared sessions for the other (?) . You can also see me attempting to login 3 times (and fat-fingering my password once) for a total of two successful logins:

BTW, if you’re interested in the stuff above watch this.

~7:40p: Set the clock ahead another 9 hours so that we’re about 10.3 hours in the future. Logged in, executed the vizzes. They’re still cached.

~11:10p:  Set the clock ahead 3 more hours. Drank more coffee. Chased the neighbors dog b/c I’m wired. By the time I got back, its about 11:10p on the server, or a little less than 14 hours after I executed my vizzes the first time. When I execute the vizzes, they run “slowly” again. No cache!

After that, checked Tableau’s Load Time report. Here’s the 9:30a load:

..and the 11:15p load.

The “cached” loads are nowhere to be found on this report, which is strange and sort of interesting.

Next, zip up the logs and run Logshark against them to see if I can pick up the “cached renders” in the Apache report it generates for me.

I can! You can clearly see the vizzes being rendered from a dead start, me hitting the cache twice, and then rendering from scratch again at the 11:15p mark.

Mystery solved.