Each of KORE's Tableau Servers is used by multiple customers, based on geographic region. Tableau Server's security measures ensure that each user can only access their own organization's data. Because Tableau reporting is very important to all KORE customers, efficiency and performance are of the utmost consideration.
KORE is unique among Tableau’s OEM partners in that we allow customers to create and publish their own Tableau content. But because the servers are shared, one user running a large and inefficient report will have a negative impact on many other users. To continue offering this flexibility, KORE works with Tableau and customers to set rules and identify best practices for custom reports.
The guidelines on this page help us ensure that Tableau Server stays responsive and efficient for all KORE customers using it. As usage and technology change, we may update these guidelines—we'll send out a notice when that happens.
If you have any questions about this document or reporting, please reach out to your Success Manager.
Metrics and best practices
KORE uses the following metrics to identify Tableau Server content for review. If any of these thresholds are exceeded, a review may take place to determine if it's sustainable. For each metric, we also suggest best practices to help you stay within the thresholds. If a report consumes too many server resources, we will try to help you make the report more efficient but we may be forced to disable it if the impact to other customers is severe.
Tableau Server Password Requirements:
- Must include letters.
- Must include at least one uppercase letter.
- Must include at least one number.
- Must include at least one special character.
- Must have a minimum length of 12 characters.
- The password will expire every 90 days.
Any data source or workbook exceeding 1MB
- While Tableau content size is not a perfect indicator of overall efficiency, it is one of the most easily available and quantifiable metrics.
- Large Tableau content size can often be reduced by more efficient underlying data sources and/or SQL queries which serve more specific, targeted objectives.
- Best Practices
- Database columns not used in reports should be hidden or not selected in the query.
- Data sources should be constructed to only return necessary fields for reporting.
- For workbooks, large size can be alleviated by closing out of unnecessary data connections and removing test worksheets before publishing to the Tableau Server.
- You can see the size of a workbook in its Details tab. You can also check the size of any files saved to your local machine.
- See also: Best Practices for Designing Efficient Tableau Workbooks
Any report utilizing 10+ filters or any drop-down filters with 100+ underlying options
- Inefficient filter usage can be one of the most significant factors in workbook efficiency. The rendering of filters occurs separately from the rendering of sheets.
- Best Practices
- Drop-down filters with the “Only Relevant Value” option selected are particularly inefficient since Tableau selects all values, sorts, and displays them all separately.
- Utilizing Tableau dashboard actions can be a far more effective choice than filters. This a dashboard design consideration worth exploring.
- Excessive filter usage can lead to very slow load times and rendering of a dashboard, so consider summarizing reports in a visual format instead of relying on filters.
- The number of filters and underlying results within a filter set is best explored within the dashboard experience. Use filters wisely.
- See also: Add Interactivity using Actions
Report design and purpose
Any report displaying more than 1,000 rows of data upon the initial load
- Tableau is intended for data visualization. Its strengths are ease of use and design options. When a Tableau report displaying upwards of 1,000 rows of data points, it requires more processing capacity, just as with filter-rendering.
- Best Practices
- Consider the usage of the final report. Are end-users consuming all 1,000+ rows of data in the visualization platform? Is the goal really about extracting data rather than rendering it on screen?
- Use Tableau Desktop to export the result set instead of publishing a report or dashboard to Tableau Server.
- For DWA customers, use a SQL scripting tool such Aginity Workbench to extract data. Reach out to KORE if you need help determining the most appropriate tools and output format.
- The number of rows of data can be seen in the bottom-left corner of Tableau Desktop when designing any worksheet.
- See also: Examples of well-designed Tableau visualizations
- See also: Tableau Server Processes
Extract refresh frequency
No single extract should be run upwards of 4+ times per day, nor average more than 10 total minutes of run time per day
- Extracts and subscriptions both funnel through the Tableau Server Backgrounder process. There is an infrastructure limitation to usage of this process.
- Long-running extracts can be particularly troublesome, as they cause a down-stream effect of system-wide lag. Anything upwards of a few minutes should be reviewed.
- If a workbook is inactive for 100 days, Tableau will automatically suspend extract refreshes. To resume the refreshes, go to Tasks > Extract Refreshes, select one or more items, and select Actions > Resume. They do not resume automatically when the workbook is opened.
- Extract schedules denoted by a "DO NOT USE" prefix are designed for and only to be used by KORE internally. These are unapproved for client usage.
- KORE maintains the right to suspend extracts operating on the unapproved schedule list. Clients will be notified that these extracts must be moved to an approved schedule.
- Best Practices
- As related to content data size, extracts should be carefully reviewed in advance to ensure they are as efficient and streamlined as possible. This can be done in Tableau Desktop upon the initial extraction.
- Data source extracts are strongly recommended over workbook extracts, so that multiple copies of the same data are not being refreshed separately.
- Any schedules of 4+ occurrences per day are utilized only for KORE's internal purposes. Please consult with KORE before choosing such an option.
- Site administrators can view current extract processes in the Tasks tab of the Tableau Server, or by navigating to the Background Tasks for Extracts dashboard in the Status tab.
- See also: Materialize Calculations in Your Extracts
No organization should utilize more than 25 minutes per day on subscription processing
- Subscriptions are often faster-running tasks than extracts, even though both run through Tableau Server’s Backgrounder process. KORE is in the process of developing external-facing reports with these metrics. DWA users can also access the Backgrounder Status dashboards on the Tableau Server site.
- Best Practices
- Dashboard subscriptions are strongly recommended over entire workbook subscriptions. Workbook subscriptions frequently result in rendering error messages.
- If subscribing a large group of users to one report, consider an Outlook forwarding rule. Set up just one Tableau subscription and have Outlook could handle the larger distribution.
- Allow extra time for extracts to process before a dependent subscription is scheduled. Since both operate on the same process, lag can greatly affect such a dependency.
- Site administrators can view current subscription process in the Tasks tab of the Tableau Server, or by navigating to the Background Tasks for Non Extracts dashboard in the Status tab.
No single report should typically be rendered more than 100 times per day (often caused by automatic-refresh or contact-embedded reporting)
- The VizQL process handles all visualization requests on the Tableau Server. As with the Backgrounder process, there is an infrastructure capacity consideration.
- Best Practices
- Contact-embedded dashboards cause a significant strain on the Tableau Server due to the frequency of visualization requests, with many running concurrently. They should always be collapsed by nature, but even in a collapsed form they often exceed these performance protection thresholds.
- Any automatic-refresh dashboards can also cause a similar strain. These are situations when some tool or plug-in reloads reports on a recurring schedule.
- No single report should be rendered this frequently through the Tableau Server due to the strain it causes on all other dashboard requests system-wide.
- Views in the last month, last three months, last 12 months and all-time can be seen from the Workbooks or Views navigation tabs.
The KORE team will continue to work directly with customers whose content negatively impacts the performance of Tableau Server. We're also exploring the possibility of moving heavy users to their own separate environments and providing a KORE plug-in, allowing them to publish their reporting more liberally.
The above thresholds will serve as a guideline for these conversations. Over time, KORE will also produce more concise reporting to demonstrate how customers are staying within these bounds.
For contact-embedded reports, please consult with the Success Team. These reports have a significant impact on Tableau Server performance, so KORE is evaluating a long-term approach. This may include moving an organization to a smaller, more dedicated Tableau Server environment instead of the larger shared ecosystem.
KORE continues to work with Tableau Software on best practices. We look forward to continued collaboration with both Tableau and all of our customers. We are committed to giving our customers the best product and experience possible while encouraging innovation and creativity. As always, please reach out to us with any questions or concerns.