TM1 Forum

Hi All,

I have an consolidation cube which is accessed by 30 - 40 users simultaneously using different views

So when users simultaneously access the same view or open them , the system gets frozen and crashed

This cube is also with huge loads of rules and calculations in it

so is this any possible way to add an parameter or something to config file to increase the accessibility for users (forgive if this sounds bad )

So please give a solution to over come this performance issue

Regards
Guru

guru1988fortm1 wrote:Hi All,

I have an consolidation cube which is accessed by 30 - 40 users simultaneously using different views

So when users simultaneously access the same view or open them , the system gets frozen and crashed

This cube is also with huge loads of rules and calculations in it

so is this any possible way to add an parameter or something to config file to increase the accessibility for users (forgive if this sounds bad )

So please give a solution to over come this performance issue

Regards
Guru

Provided that the server has the required performance capability (RAM, processor capacity and did I mention RAM?) 30 to 40 users browsing different views of a cube is nothing. If I can manage that in a 32 bit environment you should certainly be able to in a 64 bit, if indeed yours is... again, if the server is up to it. So that would be the first thing that I'd be looking at. For even if the calculation load is huge, yes, you may get a freeze but you should not get a crash. It might be an idea to provide some insight into your hardware specs, and the size of this cube.

If the rules are indeed complex the next thing I'd be looking at is whether they can be simplified. Are they the most efficient they can be? Does all of the calculated data have to be calculated live, or could it be calculated within TI and stored as static values which are periodically refreshed? Just because you can do things by rules, it doesn't necessarily mean that you should in all cases.

But in answer to your question, though there is a parameter which deals with the size of any individual view there's no parameter that does what you describe... simply because the crash that you describe shouldn't be happening in a healthy system anyway.

You can create one or more copy of the cube for reporting.
For better performance clone the cube without the rule.
You can find the necessary code here:
http://bedrocktm1.org/

Alan Kirk wrote: Provided that the server has the required performance capability (RAM, processor capacity and did I mention RAM?) 30 to 40 users browsing different views of a cube is nothing. If I can manage that in a 32 bit environment you should certainly be able to in a 64 bit, if indeed yours is... again, if the server is up to it. So that would be the first thing that I'd be looking at. For even if the calculation load is huge, yes, you may get a freeze but you should not get a crash. It might be an idea to provide some insight into your hardware specs, and the size of this cube.

If the rules are indeed complex the next thing I'd be looking at is whether they can be simplified. Are they the most efficient they can be? Does all of the calculated data have to be calculated live, or could it be calculated within TI and stored as static values which are periodically refreshed? Just because you can do things by rules, it doesn't necessarily mean that you should in all cases.

But in answer to your question, though there is a parameter which deals with the size of any individual view there's no parameter that does what you describe... simply because the crash that you describe shouldn't be happening in a healthy system anyway.

Hi Alan,

Yeah you were right , i am looking for a way to simplify my rules

This is a Consolidation Cube with only few dimensions , so the values from all cubes taken at all level and caluculated here

['All_Business','All_Insured', 'All_Sponsor','Total_Product','Booking Delay']=>DB('Consolidation',!Version,!Scenario,!Currency,!Business Type,!Country,!Operating Unit,!LOB,!Year,!Month,'GWP');

This kind of feeders are pesent in various cubes that feeds to this consolidation cube

Will this kind of feeders affect the performance

Thank You
Regards
Guru

guru1988fortm1 wrote:Hi All,
So when users simultaneously access the same view or open them , the system gets frozen and crashed
This cube is also with huge loads of rules and calculations in it

Some questions:
- Does the TM1 server actually crash or do the users think it has crashed because it is taking so long to see the results?
- How big is the TM1 server in RAM
- How much RAM do you have on the server
- Are you running 32 or 64 bit operating system.

stephen waters wrote:Some questions:
- Does the TM1 server actually crash or do the users think it has crashed because it is taking so long to see the results?
- How big is the TM1 server in RAM
- How much RAM do you have on the server
- Are you running 32 or 64 bit operating system.

Hi,

No it does not crash, it gets frozen (i misinterpreted)

RAM utilization is around 28 GB (with persistent feeders =F) and it is 64 bit operating system with 4 processors

i enabled the parallel interaction also (as i am using 9.5.2)

But still it gets frozen, if some one queries the final cube, all the input cubes on which the final cube is dependent is frozen

And it takes 3 minutes for the final cube to open

So please advice how to overcome this cube dependecny and this kind of feeders optimization

Thanks
Guru

guru1988fortm1 wrote:So please advice how to overcome this cube dependecny and this kind of feeders optimization

When you link cubes together with intercube rules and feeders you are treading down a path full of traps that can bring your system to a skreeching halt. Go back and read Alan's post. It has the ideas/issues you need to consider. It doesn't have THE answer for you because there are no easy answers. You need to experiment to find the optimal solution given your environment.