In TM1, if a TM1 Cube has huge of volume of data and rule calculation, there is possibility that TM1 takes longer time to open a cube view, to look at the issue with performance would be TM1 View Caches (Stargate Views).
The Stargate view contains only the data for a defined section of a cube and does not contain the formatting information and browser settings that are in a view object.
The purpose of a Stargate view is to allow quicker access to the cube data.
To fine tune and control the Stargate Views, TM1 provides couple of settings namely VMM (View Maximum Memory) and VMT (View Minimum Time). Both properties that needs to be set for each cube.
Any user who has access to }CubeProperties can modify the VMM and VMT Properties
VMM:
For each cube, this property determines 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.
You must, however, make sure sufficient memory is available for the TM1 server to load all cubes.
The value of VMM is expressed in kilobytes.
If no VMM value is specified, the default value is 128 kilobytes.
VMT:
For each cube, this property defines the time threshold, in seconds, beyond which the algorithm that stores 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. If there is not enough memory available to store the stargate view, TM1 purges the oldest stargate view that is not currently in use and continues to purge views in this manner until sufficient memory is made available.
If no VMT value is specified, the default value is five seconds.
If user requests a TM1 View, then the engine processes it and renders it. At such a time, the requested TM1 view is put into view cache (Stargate) when it meets the following criteria:
Example:
Monitoring/checking on stats of the memory usage and TM1 View Caches (Stargate Views)
Prerequisites:
Lets consider a cube “Cached View” which is created for illustrating the scenario with large volume of data.
Now we have data stored in a cube has memory showed in the screenshot below:
And from the screenshot below, we can see that VMM and VMT are not set. So by default VMM is 128KB and VMT is 5 Seconds
Now when we try to open a cube view which is taking more than 5 seconds i. e., VMT is 5 seconds by default and it consumes less than 128KB memory which is default of VMM. A stargate view is created as shown in the screenshot.
since a stargate View is stored in the memory, when a view is being opened by any user for the second time. The time taken is less compared to the time taken previously.
Now from the consideration, there is only 23KB is remaining out of 128K which is default VMM, when a user tries to open a new view which is taking more than 5 seconds in the same cube, TM1 will try to purge the view which is stored. But even after the view is not getting stored than, VMM and VMT properties should be set accordingly to enhance the performance.
Now set the VMM and VMT properties 240MB and 2seconds respectively as in screenshot.
When the user is trying to open/recalculate a different view, then there will be one more stored/stargate view created, as the condition VMM is more than memory of TM1 View and time taken to recalculate the view is more than VMT satisfies.
If we put a dimension which was in Title into the row and calculate the view, TM1 engine will process it. At the time of rendering, if the criteria of VMM and VMT are met, then it will catalogue this 2nd view as well. Assuming there is enough memory space left in the VMM stack, TM1 server will catalogue the 2nd view. If there isn’t enough space, then the TM1 server will purge the oldest view, until enough memory is made available for storing it.
Since in this case the memory is available for another View, there is one more view stored as shown in the screenshot below.