TM1 Design Best Practices

[aagrawal12]

Hi All,

I t would be of great help if you all can guide me to the best practices to take care while designing the TM1 Model.
Also what are the performance constraints if you can tell.
If there is such document please upload.

Thanks in advance,
Abhishek

[Alan Kirk]

I t would be of great help if you all can guide me to the best practices to take care while designing the TM1 Model.
Also what are the performance constraints if you can tell.
If there is such document please upload.

http://forums.olapforums.com/viewtopic.php?f=3&t=1037

Request for assistance guidelines (PLEASE READ)

...

* Try to make the question as specific as possible. A general question like "How do I write a rule?" is difficult to answer without copying out the whole of the user manual.

...

* Give a brief outline of what you've done to find the answer; which manuals or guides you've looked in, what tests you've done. TM1 documentation isn't the best or most logically organised, and nobody expects new users to be able to find things which are obscure. It's OK to ask a question which more experienced users might consider obvious; we've all done it. However if the person answering your question knows what you've looked at, they won't waste your time or theirs by telling you what you already know. At a minimum, please ensure that you browse the FAQ thread to see whether there is already a solution to your problem.

Beyond that, "best practices" and "constraints" will depend on how much data needs to be stored and how it's divided up, how many users need to access it, whether you're using a 32 bit or a 64 bit environment, how many rules you'll need, how complex and/or well written (or not) the rules are, how many feeders those rules will need, how many TurboIntegrator programs are needed and how often they have to run and how long they take, network speed, whether you're working with Web or another front end or perhaps using Citrix and, of course, the exact length of a piece of string.

All of these will vary on a model by model basis.

Had you looked in the FAQ thread you may have found a link to the Technical library page which will in turn lead you to the TM1 Server Administration document, which at least gives you some kind of outline of what kind of resources you'll need to run a TM1 model.

[aagrawal12]

Thanks a Lot Alan
Can u clear some of my doubts:

1)Are there any limits on how much I write a Rule?? I have idea it effects performance but if We use feeders for the rules that would not be problem.
And what I have read is there can be Feeder for every rule. What do u mean by how many feeders those rules will need???
Is there any performance issue by using the Feeders??
I am trying to create the a Model where I think I can use 12000 lines DB functions in Rules..would that be a problem??

I am using 64 bit machine.....is there any other alternative

Please suggest

Abhishek

[Alan Kirk]

Can u clear some of my doubts:

1)Are there any limits on how much I write a Rule??

That's a bit more specific but it's still going to be highly dependent on the exact structure of the rules.

There are various limits when it comes to writing rules... for example how deep you can nest If() functions, and if memory serves me correctly there's also a limit on how long a rule can be but it's so long that most people won't bump up against it.

12,000 DB() functions however sounds more like a problem in design than implementation; such rules would border on being unmanagable and certainly extremely tedious to debug. The use of more generic rules, or possibly even a change to how the data is stored in the cube(s) would be called for before I'd go down that path.

I have idea it effects performance but if We use feeders for the rules that would not be problem.

Yes it would. Or at least, potentially it would. The purpose of using SkipCheck and feeders is to ensure that the cube doesn't have to calculate every single cell in a cube, but rather only the cells that need to be calculated. But if you have highly complex rules those still need to be calculated every time they're called for the first time, or when the underlying values change. Feeders will make the overall calculation faster but they aren't a free ride. Any values which haven't been cached from a previous calculation still need to be calculated before they can be returned to the client.

And what I have read is there can be Feeder for every rule. What do u mean by how many feeders those rules will need???

Two things. The first is that the use of SkipCheck isn't mandatory. In very small cubes you can get away without using it and not use feeders at all. I generally only do that in lookup or mapping cubes which contain strings. The second is that while the general principle is that the feeder should be the one input value which determines whether there's a calculated value, some inter-cube calculations aren't always that straightforward and you need to overfeed, sometimes feeding from more than one location. This is ideally best avoided, but on some occasions it can't be. Accordingly there isn't always a strict "one to one" relationship between feeders and rules but you're right, in most cases there will be.

Is there any performance issue by using the Feeders??

Assuming that you have enough memory, most of the performance impact in feeders will be in the server startup. The server needs to "punch" the feeders into the cells that they point to, so the more feeders you have, the longer the server will take to load.

I am trying to create the a Model where I think I can use 12000 lines DB functions in Rules..would that be a problem??

See above.

I am using 64 bit machine.....is there any other alternative

Provided that you have enough memory to handle the data (including the calculations) and the feeders, I'd rather 64 bit over 32 bit any day. Not because it will affect performance as such, simply because it gives you more memory to play with. When it comes to rules, performance will be impacted by how much processing grunt your server has.