The performance of the cube view in the contributor?

[dharav]

Hello All

I have 7 cubes and each cube have one view.

All of them are opening up very quick in both contributor and architect except view 2 and view 4.

View 2 is from cube 2 and view 4 is from cube 4

Structure of Cube 2: Structure of cube 4

Region Region
Salary Info Salary Info
Month Month
Version Version
resource

Where Salary Info dim contains more than 2200 elements.Rest of the dimensions are containing not more than 18 elements .
I have not attach either any rules or any links here. It is just structure. I have also check the dimension reorder functionality to check whether any combinations saves memory or not but test result shows no change in memory. What could be the other reason?

In }cube properties cube there is no value specified in the VMM and VMT. I tried here the VMM and VMT for those two cubes but still couldn't able to find success.

All cubes view are opening up very fast except cube 2 view and cube 4 view in contributor. In Architect & in perspective (ISB), all cube views are opening up very fast.

Could you please let me know, what should i look in to further to bring performance at normal level?

Thanks

Dharav

[jim wood]

You need to give us a lot more than that. What rules are in play, dimension sizes, do you have feeders in place? Did you do this in Perf Mod? Just telling us the dimension structure of the cube doesn't tell us much at all,

Jim.

[dharav]

The required Information:

1)There is neither rule nor feeder in place yet.

2)Dimension Size
Salary Info dim 2243
Source dim 18
Region dim 27
Version dim 4
Month dim 12

3) I don't understood on Pref Mode. Could you plz eloborate. If it is about security mode than 4.

Let me know if any further information require on this


Thanks

Dharav

[jim wood]

Performance Modeller. I asked as it builds rules and feeders for you which are not always optimal. As for your cubes. Whithout knowing more about your model I can only guess it's down to cube size.

[declanr]

When you say the salary dim is 2200 elements, are they all displayed in 1 contributor view, as that would be quite a lot and not just from performance perspective but from a usability point of view also.

[dharav]

Yes it has 2200 elements in a contributor view. When i put dummy consolidation and check the performance than it was good but whenever i tried to expand that consolidation than it took quite time to load it.


Do you think the Increase in VMM and VMT would help? Right now it is at its default view.


These 2200 elements describe the name of each employee for salary detail purpose. HR has to maintain this cube and manually input the data.

Any recommendation would be welcomed.

Thanks

Dharav

[declanr]

It would take you 2 minutes to change the vmm/vmt settings then check if it improves the situation.

That being said I doubt it will help, those settings are about storing stargate views for quicker retrieval a second time round but if its fine in architect and not in contributor then value caching isn't the issue, if it was every interface would be the same. I expect the issue is just it having to display all those elements, look at how you can cut it down:
Does every region NEED to see all 2200 elements?
Can the 2200 elements be split into multiple views?

[Sebastian.Klein]

My first thought was: Why not using Perspectives or TM1Web to display all 2200 elements? If you are using Applications for HR, than you could use TM1Web to provide an input sheet.
The Performance Modeler is not the fastest frontend in the TM1 environment, so I assume that tuning the backend will not bring you any further. But if you have to use the Contributor or better Views, then I would suggest to group the employee names to have only a few consolidated elementes at beginning and you can go further down to display the employees. You could group them by the first letter of the employee name, so you have maximum 26 consolidations to show with average 85 employees under each node.

[dharav]

We are using both Contributor and Perspective. Users are highly rely on contributor as they used to with it in EP. We are trying to move them gradually from contributor to Perspective.

I like the input of yours. I tried same way, create 4 consolidation element each having 520 elements. For each consolidation, i have created the subset so that user can have for different views or from a single view they can access 4 subset. I can not create more than 4 consolidations due to conceptual reasons.


Thank you so much for your experienced Input


Dharav

[tomok]

The title "Salary Info" for a dimension doesn't sound like it accurately portrays what is actually in the dimension. 2200 different pieces of "Salary Information" just doesn't make any sense regardless of what country you are in. It sounds like this dimension may actually contain employees or something like that, in which case every user would not be needing to see all 2200 elements, but would be restricted to smaller list via security. That would also solve your performance issue and would not require a dummy hierarchy. You could also consider creating subsets to group like kind elements together as a way to cut down on the number of elements shown at any one time.

[dharav]

In the above case, I have created one view having all 4 consolidation in a same view. Now i dont want user to expand either of the consolidation. Is there any way which can disable the user from expanding these consolidation element.


Thank You

Dharav

[tomok]

In the above case, I have created one view having all 4 consolidation in a same view. Now i dont want user to expand either of the consolidation. Is there any way which can disable the user from expanding these consolidation element.

Not in a cube view unless you modify security so that the user has no rights whatsoever to any of the children.

[dharav]

Thank You all

Appreciate your Inputs