Dashboard Design for Performance

Tristan · ‎03-08-2022

Introduction

Dashboards are the only part of Incorta that many of your users will interact with and as such, you want the dashboards to provide a good experience for them. You want your dashboards to provide the right information in a visually appealing way that leads your users to insight. You also want the dashboards to be responsive as no one likes waiting around for results. This article focuses on the design elements that will make your dashboards hum.

What you should know before reading this article

We recommend that you be familiar with these Incorta concepts before exploring this topic further.

Applies to

Most of the information in this article applies to version 4.0 of Incorta and above. Where applicable, the specific versions of Incorta that are relevant are mentioned.

Let’s Go

As a best practice, it makes sense for you to design your dashboards such that users get key summary information first, i.e KPI’s, followed by Insights that provide cuts on the data that most will find useful. Including an Insight with lowest granularity detail at the bottom of your tab is a good practice as long as it does not impact performance. You should also include a quick path to related detail, either on additional tabs within the dashboard or as drill throughs to other dashboards.

This design pattern provides a clean path to Insight with the additional benefit of helping with dashboard performance. This section explains how that works as well as providing some other dashboarding tips that can help with dashboard speed.

Limit number of Insights on a tab

Prior to version 4.6, the version of Tomcat that came with Incorta only supported HTTP/1. The effect of this is that the number of Insights per dashboard that Incorta could work to render in parallel was limited to six. As a result, for sake of performance, if you are working with a version of Incorta prior to 4.6, it makes sense to limit the number of Insights to just six.

Starting with 4.6, the version of Tomcat that comes with Incorta supports HTTP/2. HTTP/2 supports unlimited parallel processes (simultaneous persistent connections) which translates to Incorta being able to parallel process a virtually unlimited number of Insights per dashboard. This is a nice feature but do not take it as license to load up your dashboard with every possible Insight that you can come up with. Less can definitely be more with regards to dashboard design and performance.

Incorta only renders the tab that you land on, not all the tabs on the dashboard at once. This means that spreading your content across tabs will effectively give Incorta less work to do which may result in faster rendering. If the most popular content is what is displayed first, a best practice, then users may not need to visit other tabs and incur the work to render them.

Recommendation Notes

Limit Insights per dashboard	If using a version of Incorta prior to 4.6, it is recommended that you stick to a maximum of six Insights per dashboard (more are supported).
Spread Insights across tabs	Place your most important Insights on the landing tab. Place less important or supporting Insights on non-landing tabs where they will not need to render until the user really needs to look at them.

Pre-filter Data

Depending on the dashboard, many, if not all, users do not need to see all the data available to the dashboard. There are several ways to pre-filter data on dashboards so that initial response time is minimized.

Applied Filters

Create Applied Filters to filter the data available on a dashboard. Applied Filters apply to all related Insights on a dashboard and are both non-updateable and invisible to users. They are always in effect.

Insight Filters

It is possible to define filters for individual Insights and limit the data that they return. Insight Filters come in different flavors and cannot be altered by users of the dashboard so review the documentation for how to define them.

Prompts

Prompts are another type of dashboard filter. They display as pills at the top of a dashboard, can be updated by the dashboard user and apply to all related Insights on the dashboard. If you set default values for your Prompts, which is not required, then the data returned by the standard view of the dashboard will be limited.

Runtime Security Filters

Runtime Security Filters are applied to Incorta table objects whenever they are queried to appropriately filter the data returned. In the case of an Insight on a dashboard, they can limit the amount of data that is returned which may speed up rendering. That said, each filtered version of a dashboard is treated like a new dashboard by the cache, so applying a Runtime Security Filter where it is not required for actual security reasons could quickly use up the cached Insight slots available to Incorta.

Recommendation Notes

Pre-filter data on your dashboards

Choose the appropriate filtering mechanism if pre-filtering is warranted. Options for filtering include

Applied Filters
Insight Filters
Prompts
Runtime Security Filters

Schedule Dashboards

When a dashboard is selected in Incorta, it will either use the Incorta engine to get results or it will load directly if the current data state of the Insights on the dashboard have been cached. Cached Insights render almost instantaneously and scheduling your dashboards is a way to get a leg up on caching them for your users.

First, however, let’s talk about what happens when the engine renders your dashboards. There are three different possible behaviors if the engine is used. They are listed here in order of speed from slowest to fastest.

Columns not in memory - For columns from the dashboard that are not in memory, the engine loads them into memory from disk and the analyzer waits for the columns to be loaded before displaying the Insights that use them. Columns may not be in memory because this is the first time that they are being used since the last restart of Incorta or because they have been evicted from memory because they have not been used for a long time or because Incorta’s memory is constrained to the point that it needs to evict columns on a regular basis in order to support all of the requests for different column coming in.
Columns in memory, but need to be updated - For columns that are in memory but are not up to date based on the latest incremental load, the engine will load the incremental column data into memory before the analyzer is able to display the Insights that use those columns.
Columns in memory - For columns that are already fully in memory, the analyzer will retrieve those columns needed for each of the Insights on the dashboard.

Because cached Insights render the fastest, it is desirable to get dashboard Insights into cache as soon as possible. This happens the first time that a dashboard is requested, meaning that the first person to visit a dashboard after a data load will wait for the engine to render any Insights affected by the load and every other person after that will get the advantage of the cached Insights until the next data load completes.

An alternative to letting the first user trigger the caching of dashboard Insights is to send or schedule a delivery of the dashboard prior to the time a user gets to it so that all users that manually visit the dashboard get the advantage of the cache. Sending a dashboard triggers the dashboard to be run so that the result can be sent.

This strategy works well if the data underlying the dashboard is not refreshed frequently. If, for example, you load your data once per day overnight during off hours, it could be convenient to set up a scheduled delivery of an important dashboard that depends on the data to a service account sometime in the early morning before the standard workday has begun. If the data is being updated frequently during the work day, then you can still try to time a scheduled job after each load but be aware that a user might visit the dashboard before the scheduled delivery has a chance to execute so they may occasionally be the ones who wait for the engine to complete the work that it needs to do.

It is worth noting that if you are using Runtime Security Filters on your tables such that record level security is applied to an Insight, then each person’s “version” of the Insight, i.e. with their filtered data, counts as a separate Insight to be cached. It may not be worth employing this strategy to dashboards with Insights affected in this way or limiting the strategy to only a few specific users. Additionally, any Insight that uses the $currentTime global variable will not cache as this value is constantly changing.

Also, it is likely not necessary to schedule a delivery job for every dashboard. For many, the difference between rendering from engine vs. cache will be minimal and not worth the extra resources needed to schedule a send of the dashboard. Reserve this strategy for high traffic or high importance dashboards.

Note that there are two Tenant level configurations in the CMC that control how many Insights can be cached at one time: Maximum cached insights and Maximum Cached Memory (%). The lower between the two of these determines how many Insights can actually be cached. The default for Maximum cached insights is 2,000. If you have more than two thousand Insights in your tenant, you may want to work with your Incorta administrator to raise that value. Maximum cached memory (%) can be set between 0 and 5 with a default of 1. The value you choose indicates the percentage of off-heap memory available to store cached reports.

Recommendation Notes

Schedule dashboards

It is possible to schedule slow or high importance/traffic dashboards to deliver to a service account in order to take advantage of caching the Insights on the dashboards for faster rendering speed. This strategy is not usually needed and should probably be used after optimizing elsewhere first.

Individual Insight Tips

Another way to speed up your dashboards is to make sure that the individual Insights on each dashboard are optimized. Above, we mentioned that applying Insight filters is one way to reduce the amount of data an Insight returns. Following are a couple of other suggestions that will help with speeding up specific Insights.

Specify a Base Table

Depending on how you define joins in your schemas, it is possible that Incorta may have several different join paths to choose from as it goes after data in an Insight. Incorta may not always choose the best path but you have the ability to define a Base Table in your Insight to force Incorta to use the most efficient join path for that specific particular measure.

As you are building your Insights, use the Query Plan Viewer to review the query plan for each of your measures. If you identify a measure with an inefficient query plan, you can specify a base table to remedy the inefficiency. See Docs for instructions on how to set base tables for your measures. Once you have set a base table for the measure, use the Query Plan Viewer again to verify that the query plan looks right.

Recommendation Notes

Use Base Tables to correct inefficient query plans

Use the Query Plan Viewer to help you understand where query plans are inefficient and to verify that you have corrected them with your Base Table definition.

Advanced Maps

Starting with version 4.9 of Incorta, the Advanced Map visualization was introduced. It integrates with Mapbox to provide, as the name indicates, a more advanced way to work with and represent geo data in Incorta.

Advanced maps give you more bells and whistles to work with but If you have millions of data points (e.g. longitude/latitude sites), showing all of them initially on a map can slow down your rendering time. It may make sense to show aggregated data only on an initial map and then provide a drill through to another map with all the detail. This allows you to limit the number of data points on both maps and make the rendering of the maps much quicker. For example, you may show aggregated sums or counts at the country or state level on the initial map. Then when the user drills down to the detail level, instead of rendering the millions of sites available across the globe, the second map will filter based on what was selected in the first map and will only need to render the data points in one country or state.

Be aware that satellite image maps carry much more information than the other types of maps. As a result, they are slower to render as there is much more data to transfer from Mapbox to Incorta. Consider using one of the other map types (Outdoors, Light or Dark) to speed up rendering if needed.

Incorta comes with a license for a highly functional standard version of Mapbox. There are many flavors of Mapbox, for example with the Boundaries product, that allow you to add other features to your maps like congressional districts or neighborhoods as layers that overlay the standard product. While these do not increase the speed of your map visualizations, they do give you other options that you can leverage inside of Incorta. If you choose to purchase your own Mapbox license, you can work with Incorta to replace the default license with your own and take advantage of the features that you have purchased.

One of the great features of Advanced Maps is the layer feature but having too many layers can impact performance. Where you can, keep it simple and limit the number of layers you create. Note that in version 5.2, a new cluster feature is planned for release. This feature presents bubbles with counts that disintegrate into smaller bubbles as you zoom in until eventually you get to individual data points and all in a single layer.

Recommendation Notes

Drill through maps with summarized data to maps with full detail	Reduce the amount of data maps need to render by using one map to filter the data that is displayed on the detail or transaction level map.
Use non-satellite maps	Non-satellite map types have less intrinsic data and therefore render more quickly than satellite maps.
Consider using your own Mapbox license	Additional Mapbox features are available if you acquire your own license and then configure Incorta to use it.

Analytics Service

When your Analytics Service is overworked, your users can experience delays that have nothing to do with the design of your dashboards. If you notice general dashboard response slowness, the first thing to check is your Analytics Service settings. The Performance Tuning section on Docs has recommendations for how the settings should be set for optimal performance. Work with your Incorta Administrator to verify your settings and make adjustments if necessary.

If your settings are OK, then your Analytics server may just be overloaded by the number of requests it is receiving. Over time as Incorta is more used, dashboard requests which are handled by the Analytics service may increase. In this case you can add another Analytics node to your cluster to handle the traffic. Note that you will need to evaluate your hardware topology to determine how to best accommodate another analytics node. Work with your Incorta administrator or your Incorta Customer Success representative if you need assistance.

A coming Incorta Cloud feature will allow you to set up dedicated analyzer nodes. You can designate the analyzer nodes to be available to a specific Incorta Group or even for specific dashboards. The value of this feature is that you can provide a specific audience with consistent performance. Keep an eye out for this feature if you are an Incorta Cloud customer.

Recommendation Notes

Adjust Analytics Service settings	Use the guidance in the Performance Tuning Guide to adjust the Analytics Service settings if needed.
Add an Analytics Node	To expand capacity, add another Analytics node