TM1 Forum

Hi All,

We are using Executive viewer to view the reports (Cube View). Reports take almost 5 mins, if calculations are not in cache.
To get the calculations pre-cache used ViewConstruct in TI process.

Thought of having a stargate view. Now after going through some documentations, found that we need to have some value in }CubeProperties for VMM & VMT.
Do we need to make any changes in .CFG file for stargate views?

When we say Stargate Views, do we need to use ViewConstruct to get respective data in to cache?

Now to keep the calculations in cache, my approach was to have a chore which will trigger TI process having ViewConstruct every 3 hours.
Is there any other alternative that can be tried out.

I went through the documentation but concept of stargate view is not yet clear for me.
Need more information on stargate views.

Regards,
Deepak Jain

Before delving into all this, are you sure that the cube is performing well, outside of EV?
For example in the Cube viewer, does the same view take as long to calculate?
If yes, why does it that long? Too many rules and feeders? Too many data? Cube that is not set up in an optimal way? ...
Maybe use TI to fill such a Reporting cube out of several other cubes, and report on that more lightweight cube.

Hi Wim,

I would have added it in my earlier post, but it's never late.

Yes it takes same amount of time in Cube Viewer.

Earlier the time taken was around 13 mins.
So we make changes to feeders and time came down to 5 mins.
Optimized the cube using cube optimizer.

Yes too many rules and feeders.
Business wants real time calculations and forced to use rules rather than TI.

Regards,
Deepak Jain

Please tell us more about the cube. What is done so that the calculation takes 5 minutes?
Are you feeding entire scenario's/versions?
Do you overfeed a lot? Do you feed correctly? Do you ALWAYS feed only to N-level cells?
Do you have ConsolidateChildren type of rules?
Did you investigate which rules and feeders in particular are heavy? (if you don't have a clue from just reading the rules)
Is the developer/development team a competent person/team in TM1, given that it's not a simple cube?
And so on. 5 minutes is just way too long.

Hi Wim,

Cube is having 7 dimensions

Dimension	No. of leaf level	Max. consolidated level
DIm1	199	6
DIm2	377	4
DIm3	702	10
DIm4	1	2
DIm5	14	2
DIm6	33	3
Measure Dim	4	0

Wim Gielis wrote: Are you feeding entire scenario's/versions?

Yes, as rules are calculated based on single elements. There around 120 rule statements which are as below example.
A=B*C;
D=E\F;

B, C, E & F can be a consolidated element as well.

Wim Gielis wrote: Do you overfeed a lot? Do you feed correctly? Do you ALWAYS feed only to N-level cells?

After making changes, I don't think overfeeding could be a reason. I will re-check on that.
Can underfeeding also be a reason for more time consumption??

Wim Gielis wrote: Do you have ConsolidateChildren type of rules?

No.

Wim Gielis wrote: Did you investigate which rules and feeders in particular are heavy? (if you don't have a clue from just reading the rules)

How can we investigate which rules and feeders are heavy in particular?

Regards,
Deepak Jain

Hello

Cube is having 7 dimensions

Do the small and sparse dimensions are at the beginning of the cube and the large and dense dimensions at the end?

How can we investigate which rules and feeders are heavy in particular?

Turning off the rule or feeder, bounce the server to flush the memory, and see the impact.
Also, check out the control cubes in TM1 that store number of feeders, amount of memory used, and so on.
Assess the difference when making a change to a certain rule or feeder (or even completing putting it in commentary).

Can underfeeding also be a reason for more time consumption??

Underfeeding? No, to the contrary. If you feed less cells, TM1 has less work to do when computing the aggregations. But chances are that the result is not correct.

Yes, as rules are calculated based on single elements. There around 120 rule statements which are as below example.
A=B*C;
D=E\F;

B, C, E & F can be a consolidated element as well.

With only the information from this topic, I *expect* this to be the cause of the slowliness.
You are using a lot of feeders, more than optimal to have a fast computation time for your view.
But to be honest, I have used EV in the past as well, and IIRC, we had to feed more than we should do in "plain TM1" because EV expects cells to be fed (or base data).
Tricks like adding B as a child of consolidated A might not work, but please check this out. Turn A into a consolidated member with B as child.
If B is properly feed or base level data, this could in turn "feed" A. Make sure the rule for A is not restricted to N-level anymore (as it's always a C now).

Most of all, see if your report continues to work if you do not feed your C-level rules.

Wim