Two Tips To Make Your DivePort Run Faster

The most wonderful thing about Diver is its ability to handle very disparate data and seamlessly present that data to end users in forms that are useful for making decisions. Many Diver administrators pack Models with all available data to be sure "a single version of the truth" is achieved. The downside to manipulating these huge amounts of data is that DivePort portals can load slowly from time to time, depending on how they were built. This only leads to disgruntled users. To prevent this, follow these two tips for making your DivePort run faster.

1. Create Smaller Separate Models:

Many companies start their DivePort portal with a Dashboard—an overview or summary of data that is important to view first. Then, optimal dives contain detailed data, allowing users to research sources of positive or negative alerts on the Dashboard. Because it draws on a wide variety of source information, the Dashboard can be the worst offender when it comes to slow load times—but not when you use a "Dashboard Model." Create a separate Model for your Dashboard. Essentially, squeeze all the necessary information for your Dashboard portlets into one significantly smaller Model and eliminate any unnecessary information. Because your Dashboard is opening only one "trim" Model—instead of a multitude of separate Models for every gauge, bar chart, and indicator—load time speeds up tremendously.

As you may deduce from the implications of this tip, fewer Models equals faster load times—but keep in mind that you frequently can't have just one Dashboard Model. For instance, if your DivePlan with detail Models includes:


then using such a DivePlan for the purpose of creating a dashboard would result in a slow response time.

To improve performance speed, create parallel Models to the detail Models and call them "Dashboard Models."

These Models have only the data that is needed for the Dashboard:


Now, any indicators or measures portlets on the Dashboard would use the DivePlan with the small Models as a starting point. Any Click Action that opens detail Reports would open Markers that use the big detail Models with all the required data elements.

2. Follow these "Do's & Don'ts" for reports and markers:

• a. Never start your dives with Info Fields—use Core Dimensions.
• b. Try to include (if applicable) as many calculations at the Model level as possible,
      instead of creating them in a Report on the front end.
• c. QuickViews should be based on Dimensions instead of Info Fields.
• d. Position the TimeSeries QuickViews at the end of a set of QuickViews, instead of
      at the beginning.
• e. Take advantage of tuning mechanisms in Builder:
• Make the Blocking Factor 3–5% of the data set.
• Calculate DimCount using the DimCount option in Builder when the Model
  is being generated.

As always, remember that every data set is unique, and these recommended changes should be based on the data structure at the back end, in addition to user needs on the front end.

Special thanks go to Darius Kokott and Wendy Wolfberg for their valuable contributions to this month's Dashboard Design 101 article.