Are you facing the situation that your Tableau server backgrounder jobs have much longer delay during peak hours ?
There are many good reasons why extracts are scheduled at peak hours, likely right after nightly ETL completions or even triggered automatically by ETL completions.
You always have limited backgrounders that you can have on your server. How to cut average extract delay without adding extract backgrounders and without rescheduling any extract jobs?
The keyword is job PRIORITY. There are some good priority suggestions in community(like https://community.tableau.com/thread/152689). However what I found the most effective approach to prioritize the extracts was duration based priority in additional to business criticality – I managed to reduce 50% extract waiting time after increased priority for all extracts with duration below median average runtime.
Here is what I will recommend as extract priority best practices:
- Priority 10 for any business critical extracts : Hope nobody will disagree with me to give highest priority to business critical extracts..
- Priority 20 for all incremental extracts : Not only normally incremental takes less time than full, but also it is an awesome incentive to encourage more and more people use incremental extracts
- Priority 30 for any extracts with duration below median average (this is 50% of all extract jobs). This is another great incentive for publishers to make their extracts more effective. It is the responsibilities of both server admin and publishers to make backgrounder jobs more effective. There are many things that publishers can do to improve the extract efficiency : tune extracts to be more efficient, use incremental vs full extracts, hide unused columns, add extract filters to pull less data, reduce extract frequency, schedule extracts to off-peak hours, or better run extracts outside of Tableau by using Tableau SDK (see my blog @http://enterprisetableau.com/sdk/), etc.
- Priority 50 for all the rest (default)
- Turn on tabadmin set backgrounder.sort_jobs_by_run_time_history_observable_hours 36 which will prioritize full extracts in the same priority to run in order from shortest to longest based on their “last” run duration.
The combination of #3 and #5 will reduce your extract waiting time dramatically during peak hours.
What is this backgrounder sort by run time option (#5 above)? I am sure that you want to read official Tableau online help here.
In short, Tableau server can sort full extract refresh jobs with the same priority (like 50) so they are executed based on the duration of their “last run,” executing the fastest full extract refresh jobs first.
The “last run” duration of a particular job is determined from a random sample of a single instance of the full extract refresh job in last <n> hours which you can config. By default this sorting is disabled (-1). If enabling this, Tableau’s suggested value is 36 (hours)
Let’s say that you have the following jobs scheduled at 5am, here is how extracts are prioritized:
|Priority||Job Name||Duration (min)||Background priority with sort_jobs_by_run_time option ON||Background priority with sort_jobs_by_run_time option OFF|
|10||Job 10.1||2||1||Those 4 jobs will go fist one by one w/o any priority among them. i.e. it could be Job 10.4, then Job 10.2, then Job 10.3 and Job 10.1|
|20||Job 20.1||1||5||Those 4 jobs will go one by one after all pririty 10 jobs. Again no priority among them.|
|30||Job 30.1||2||9||Those 4 jobs will go one by one after all pririty 20 jobs. Again no priority among them.|
|50||Job 50.1||1||13||Those 10 jobs will go one by one after all pririty 30 jobs. Again no priority among them.|
For example, the max waiting time for the 1 min Job 20.1 will be 29 mins (all priority 10 jobs) with sort_jobs_by_run_time option ON. However the max waiting time could be 60 min with sort_jobs_by_run_time option OFF (all priority 10 jobs + other priority 2 jobs).
Re-cap on how extracts are run in this order:
- Any task already in process is completed first.
- Any task that you initiate manually using Run now starts when the next backgrounder process becomes available.
- Tasks set with the highest priority (the lowest number) start next, independent of how long they have been in the queue. For example, a task with a priority of 20 will run before a task with a priority of 50, even if the second task has been waiting longer.
- Tasks with the same priority are executed in the order they were added to the queue except if tabadmin set backgrounder.sort_jobs_by_run_time_history_observable_hours 36 is turned on. When the above option is on, the fastest full extract refresh jobs go first.
A few final practice guide:
- Step 1: If most of your extracts have priority 50. You may want to try just turn on tabadmin set backgrounder.sort_jobs_by_run_time_history_observable_hours 36 to see how much waiting time improvement you can gain.
- Step 2: If step 1 does not give you what you are looking for, try to change extract priority to higher priority (like 30 ) for any extracts with duration below median average. This will give you big waiting time reduction. You can start to change the extract priorities manually to see how it goes. Just be aware that any re-publishing of extracts will change priority back to default 50.
- How to automate Step 2? I have not seen API for it. However I just had a program to update tasks.priority directly.
- Why I do not recommend to have higher priority for more frequent jobs? I know that it is one of the recommended best practices by a lot of Tableau practitioners. However I just think that it drives a wrong behavior – it will encourage publishers to increase the extract from weekly to daily or to hourly just in order to get their jobs higher priority, which in turn causing more extract delays. I think that job duration and incremental high priority give much better incentive for publishers to make their extracts more effective, which becomes a positive cycle.