In a perfect world, users working with Tableau Server will hit a VizQL Server process with a well-populated cache to increase perceived performance of the server.
The world isn’t always perfect.
Yesterday, I learned something I wasn’t aware of when it comes to our caching mechanism. I thought I’d pass it along.
As you may know, a VizQL process caches at multiple levels:
- Model Level: Has this VizQL process done the computations to display a particular view before? If it has, it can send the pre-computed results back to the browser with a minimum of extra work.
- Query Level: Maybe we haven’t computed the model yet, but we have run a query or queries which give us results we need. We therefore can avoid round trips to the data source and the latency associated with same.
Getting a cache hit against a model allows us to do the least possible work – so we want to make sure we maximize our chances of getting that hit.
Anyhow, part of what Tableau does to determine whether it can re-use a computed model in the cache is to look at the size (physical dimensions) of the model.
If two users ask for the exact same view, but are running browsers with different display sizes, the view which gets displayed in the browser is different as far as Tableau is concerned because we’re sending two different sizes to best fit in each user’s browser. No cache hit!
Lesson learned: If you create a dashboard and stick with the default “Automatic (Fit To Window)” setting, you could potentially be shooting yourself in the foot as far as the model cache goes – Tableau will happily resize each viz in your dashboard to fit into the different browser window sizes it’s dealing with…and your cache hit ratio could go way down.
Solution: Always choose an exact size for your dashboard.
