TM1 Stargate Views Explained

There are various approaches available to enhance the performance of your TM1 application. One such approach is to leverage Stargate Views.

Stargate Views are different from traditional view objects and represent cached subsections of cubes that get created through user experience. As users browse cubes via the Cube Viewer or consume cube data via Cognos BI reports and analyses, these subsections get stored according to the current title elements/context and row and column subsets being requested.

To fully understand the benefit of these Stargate Views, it is helpful to consider how TM1 responds to a user’s request for data. If the request requires aggregation along any number of dimensions, that aggregation is done on the fly. Depending upon the size and sparsity of the cube, this can be a time consuming effort. In cases where a Stargate View coincides with the incoming user request, the Stargate View fulfills that request and negates the need for on-the-fly aggregation – resulting in markedly better performance. Recent tests against a 7GB+ TM1 cube show an increase in Cognos 10.2 report render time performance from 64 seconds prior to a Stargate View being created to less than 2 seconds with a Stargate View.

Stargate View Persistence

Cached Stargate Views for each cube are persisted until one of the following conditions is met:

• The cached view is cleared if there is any data change to the specific cube in question or to any cubes on which it depends. Rules and feeders determine these cube dependencies. As an example, a daily cube data load or change to a cell value by a user would clear all stored caches for a cube. If your cube is frequently updated, you may not be able to take full advantage of Stargate Views.
• These cached views will persist until such time as the memory usage for all cached views of this same cube reaches a threshold known as VMM. At that point, the oldest cached view is discarded in favor of any new cached views. VMM is described in more detail below.
• A restart of the TM1 application will also clear the cached views.

Monitoring Stargate View Usage

In order to understand the extent to which your TM1 application is leveraging Stargate Views, you can reference a control cube named }StatsByCube.

The }StatsByCube control cube captures information about the cubes in your TM1 application. You’ll need to enable Performance Monitor either by right-clicking on your TM1 instance in Architect and choosing Start Performance Monitor or by adding PerformanceMonitorOn=T to your TM1s.cfg file – the latter change requires a service restart to take effect.

After Performance Monitor starts, it takes a few seconds for the counters to begin writing to the }StatsByCube cube.

When you open }StatsByCube, the most useful view when starting out is to put the LATEST member from the }TimeIntervals in the title and the }StatsStatsByCube and }PerfCubes dimensions in the rows and columns. The counters you want to focus on are Memory Used for Views and Number of Stored Views. These represent the amount of RAM (in bytes) used for Stargate Views and the number of Stargate Views created for this specific cube.

As your users consume the cube via TM1 client tools or Cognos BI, you will see these numbers rise until one of the conditions mentioned previously occurs and/or the cached views are flushed.

Controlling Stargate View Behavior

As an administrator, you have some control over how and when Stargate Views are created and how much RAM they consume. This is done through the View Maximum Memory (VMM) and View Minimum Time (VMT) thresholds set in the }CubeProperties control cube.

VMM

VMM defines the amount of RAM reserved on the server for the storage of Stargate Views. The more
memory made available for Stargate Views, the better performance will be. When changing this value it is important to ensure that sufficient memory is available for the TM1 server to both load all cubes and support the new VMM setting.

The range of valid values (in bytes) for VMM is 16,384 (16KB) to 4,294,967,296 (4GB). If not specified the value will grow as needed until it reaches the maximum value.

VMT

VMT defines the time threshold (in seconds) beyond which the algorithm that stores the TM1 Stargate Views is triggered. If the time required to calculate a cube view surpasses the specified threshold, TM1 attempts to store a Stargate View. For this reason, setting this number to a higher value will usually result in relatively fewer Stargate Views being created.

The default threshold is 5 seconds; however this value can be set for a range of 1 – 259,200 seconds (1 sec to 72 hours).

Maintaining Stargate Views to Improve the User Experience

You can take advantage of the ViewConstruct function to prepopulate cached views. For example, if you load data into a TM1 cube (or the cubes on which the cube in question depends) on a scheduled basis, you can create a TurboIntegrator process to execute the ViewConstruct function against View objects you create that are representative of the subsections of the cube most in demand by your users. This process would be executed after your data is loaded.

If leveraging TM1 as a data source for Cognos BI, you can create a job to run a series of frequently used reports to achieve much the same effect. The creation of cached views as a result of this “pre-cache” job will improve performance for your end user community.