OEG Best Practice: Dashboard settings for improved model performance
Overview
A dashboard with grids that includes large lists that have been filtered and/or sorted can take time to open. The opening action can also become a blocking operation; when this happens, you'll see the blue toaster box showing "Processing....." when the dashboard is opening. This article includes some guidelines to help you avoid this situation.
Rule 1: Filter large lists by creating a Boolean line item
Avoid the use of filters on text or non-Boolean formatted items for large lists on the dashboard. Instead, create a line item with the format type Boolean and add calculations to the line item so that the results return the same data set as the filter would. Combine multiple conditions into a single Boolean value for each axis.
This is especially helpful if you implement user-based filters, where the Boolean will be by the user and by the list to be filtered.
The memory footprint of a Boolean line item is 8x smaller than other types of line items.
Known issue: On an existing dashboard where a saved view is being modified by replacing the filters with a Boolean line item for filtering, you must republish it to the dashboard. Simply removing the filters from the published dashboard will not improve performance.
Rule 2: Use the default sort
Use sort carefully, especially on large lists. Opening a dashboard that has a grid where a large list is sorted on a text formatted line item will likely take 10 seconds or more and may be a blocking operation.
To avoid using the sort: Your list is (by default) sorted by the criteria you need. If it is not sorted, you can still make the grid usable by reducing the items using a user-based filter.
Rule 3: Reduce the number of dashboard components
There are times when the dashboard includes too many components, which slows performance. Avoid horizontal scrolling and try and keep vertical scrolling to no more than three pages deep. Once you exceed these limits, consider moving the components into multiple dashboards. Doing so will help both performance and usability.
Rule 4: Avoid using large lists as page selectors
If you have a large list and use it as a page selector on a dashboard, that dashboard will open slowly. It may take 10 seconds or more. The loading of the page selector takes more than 90% of the total time.
Known issue: If a dashboard grid contains list formatted line items, the contents of page selector drop-downs are automatically downloaded until the size of the list meets a certain threshold; once this size is exceeded, the download happens on demand, or in other words when a user clicks the drop down. The issue is that when Anaplan requests the contents of list formatted cell drop-downs, it also requests contents of ALL other drop-downs INCLUDING page selectors.
Recommendation: Limit the page selectors on medium to large lists using the following tips:
a) Make the page selector available in one grid and use the synchronized paging option for all other grids and charts. No need to allow users to edit the page in every dashboard grid or chart.
b) For multi-level hierarchies, consider creating a separate dashboard with multiple modules (just with the list entries) to enable the users to navigate to the desired level. They can then navigate back to the main planning dashboard. This approach also de-clutters the dashboards.
c) If the dashboard elements don't require the use of the list, you should publish them from a module that doesn't contain this list. For example, floating page selectors for time or versions, or grids that are displayed as rows/columns-only should be published from modules that do not include the list.
Why? The view definitions for these elements will contain all the source module's dimensions, even if they are not shown, and so will carry the overhead of populating the large page selector if it was present in the source.
Rule 5: Split formatted line items into separate modules
Having many line items (that are formatted as lists) in a single module displayed on a dashboard can reduce performance as all of the lists are stored in memory (similar to Rule 4). It is better, if possible, to split the line items into separate modules. Remember from above, try not to have too many components on a dashboard; only include what the users really need and create more dashboards as needed.
Author David Smith.
Contributing author Guillaume Arnaud.
Comments
-
Thank you @DavidSmith for the great info.
Question for clarification on the following:
@DavidSmith wrote:Rule 1: Filter large lists by creating a Boolean line itemAvoid the use of filters on text or non-Boolean formatted items for large lists on the dashboard. Instead, create a line item with the format type Boolean and add calculations to the line item so that the results return the same data set as the filter would.
This is especially helpful if you implement user-base filters, where the Boolean will be by user, and by the list to be filtered.
The memory footprint of a Boolean line item is 8x smaller than other types of line items.
Here, are you referring to the memory footprint of the filter on the dashboard? Or of the line item itself?
Asked another way: say I have 5 line items of varying data types (numeric, boolean, list) that I wish to use in a filter that will be applied to a Saved View that I published to a dashboard. From a simplicity and maintainability perspective, it would probably be best to create a 6th line item, of data type boolean, and combine logic for all 5 line items into a single Show/Don't Show boolean line that is the only line item referenced in the filter. However, my understanding is you're saying that creating that 6th line item and having the filter only refer to #6 instead of #1-5 will also improve performance because it reduces the memory footprint of the dashboard, which reduces the time the dashboard will take to load. Is that a correct understanding?
0 -
Hi
The memory footprint might be confusing here, but boolean's do use less memory becasue they can on;y have two states; True orr False.
But to answer the quesiton, yes, your approach is correct. The filter works fastest with a single Boolean line item that does not apply to time or versions, so creating a Boolean line item to represent a combination of other slower filter types will improve performance of the view.
The extra model size created by a Boolean line item is a small trade-off for the improved filter performance.
I hope this helps
David
1
