TM1 Forum

Hi All,

Buliding a cube view takes almost 10 mins to build. What could be possible reasons for taking so much of time?

Regards,
Deepak Jain

deepakjain2020 wrote:Buliding a cube view takes almost 10 mins to build. What could be possible reasons for taking so much of time?

Well...... it could be a because there is a lot of data with complex calculations and you are looking at the results for the first time
or
It is a badly designed system with poor feeders
or
anything in between.

Which do you think it is?

If you give some more (or indeed any) information then maybe some of the more technical contributors may help

stephen waters wrote:If you give some more (or indeed any) information then maybe some of the more technical contributors may help

Indeed. Please read the request for seeking assistance guidlines: http://www.tm1forum.com/viewtopic.php?f=3&t=1037

Thanks

I will be trying by making changes to existing feeders, so that there is no over-feeding or under-feeding.
I will be surely sharing a similar model if time for opening of cube doesn't comes down.

Regards,
Deepak Jain

Hi Stephen,

Cube is having 7 dimensions.

• Dimension, Elements, Maximum Consolidation Level

• DIM1, 249, 6

• DIM2, 419,4

• DIM3, 2, 1

• DIM4, 66, 3

• DIM5, 898,10

• DIM6, 23, 2

• DIM7, 4, 0

Following are few information

Cube size: 68.5 MB
Feeder: 1.36 GB

Stats of Cube

Memory Used for Views: 270336
Number of populated numeric cells: 3951688
Number of Fed Cells: 75624889
Memory Used for calculations: 226484992
memory used for feeders: 1409286144
memory used for input data: 226489344

I will like to know what sources will help me in understanding whether changes are going to help in performance improvement?
If any more information is required, please let me know.

Regards,
Deepak Jain

Looking at the size of your feeder file I think it would be beneficial if you provided the contents of the entire rule sheet for the cube. That is not to say a feeder file of that size is inherently a bad thing, there can be many good reasons for large feeder files but it would be my first port of call to look at.

Stupid question ... are you using persistent feeders? If yes, have you worked on your feeder rules, while PF was turned on?
This would simply add all created feeder flags to a static file, what blows it up over time.
And finally, have you ever deleted your .feeder files to force a recreation after application restart?

Hi Gabor,

Yep question is stupid, but I learned something.

Yes persistent feeder is on.
I have never deleted .feeder files.

Might be a stupid one again.
Do we need to delete all .feeder files related to specific cube or only .feeder file of respective cube?

Regards,
Deepak Jain

If you delete your feeder files then you server start time will increase as it will rebuild them. The file should be updated every time you make a rule change or the cube is saved.

Best practice is to delete them all, the server startup will look for inconsistencies anyway.
My personal preference is to have PF turned off during feeder development, so a simply unload of the cube can clear the pre-existing feeders and then saving the updated rule, which fires the feeders again.

Gabor wrote:The server startup will look for inconsistencies anyway.

To be exact t only checks the date stamp of the feeders file compared to the CUB and RUX files. It does not check the content of the feeder file,

Jim.

Hm, I think that's a misunderstanding, as we were talking about the deletion of the file(s) anyway.
I was referring to a situation, where (from server point of view) the deletion of a subset of .feeder files leads to an inconsistency, what usually requires a second restart of the server after complete deletion of all .feeder files. All of that is done automatically, however I haven't rechecked if the threshold of recent releases is one or two missing files to enter that loop.

What about .blb file,Doesn't it has to deleted as well,though nothing to do with performance. Thanks

.blb files store formatting information for view and rules. They have nothing to do with persistent feeders. The only quirk with .blb files is that if you intend to copy rules from one server to another then you have to either make sure to copy the associated .blb file or erase the existing .blb file on the target.

Thanks a lot,Tomok.

jim wood wrote:

Gabor wrote:The server startup will look for inconsistencies anyway.

To be exact t only checks the date stamp of the feeders file compared to the CUB and RUX files. It does not check the content of the feeder file,

Jim.

Hi Jim,

Feeders file can have latest timestamp than that of CUB and RUX file? or they all should be in sync?

Regards,
Deepak Jain

It's an or, not an and. You could have made data changes that would impact the CUB file date and therefore feeders that come from the new data. You could have also updated the rules. As rule data isn't stored the CUB file won't change.

Gabor wrote:Best practice is to delete them all, the server startup will look for inconsistencies anyway.
My personal preference is to have PF turned off during feeder development, so a simply unload of the cube can clear the pre-existing feeders and then saving the updated rule, which fires the feeders again.

Hi Gabor,

I have been going around deleting feeder and restart, so that feeders get fired again.
But sometimes the feeders file is of 1Kb and when I save the rule respect to that cube, it starts firing feeders and file size starts increasing. Hope it gives correct result.

If there are anything else to be considered rather than saving rule so that we won't have to restart the TM1 instance, please let us know.

Regards,
Deepak Jain

Deepak,
I think we talk about 2 different situations, however I am not sure, if I fully understand your question.

#1
If you restart a TM1 service after deletion of all .feeder files, there is no need to touch any rule and save it again.
TM1 has calculated all feeder flags during startup phase and it has stored this information in the .feeder file to make a subsequent restart faster.
All data being added later will be written to the .feeder automatically. There is no invalid information (overfeeding) in the file(s) as long as the feeder rule remains untouched.

#2
You change a feeder rule and save it
a) If PersistentFeeders is turned on, your pre-existing .feeder files still contain the prior feeding information, the new feeder flags are added to the file on top, which now contains 2 (or more) versions of feeding (potentially overfeeding).
That's the point where I had recommended to stop TM1, delete the files and start the server again.

b) If you continue to do feeder rule changes, you may think of turning off the PersistentFeeders until you are done.
If you then go and unload the cube and resave all rules, which do feeding in that particular cube, you don't need to restart the server.

Note:
There are many more things to say about this topic, I tried to keep it simple, so I have pointed you to the safest way.
The PersistentFeeders = T is made for case #1, if you run case #2 with it and resave/change feeder rules you need to refresh the files.

Regards
Gabor

Gabor wrote:
You change a feeder rule and save it
a) If PersistentFeeders is turned on, your pre-existing .feeder files still contain the prior feeding information, the new feeder flags are added to the file on top, which now contains 2 (or more) versions of feeding (potentially overfeeding).

I might have to get some more info.
Feeder flags will be added only for changes done or it will start adding from beginning?

Gabor wrote: That's the point where I had recommended to stop TM1, delete the files and start the server again.

The process which I followed was deleting feeders file when server was running and then starting the server.
Is that could be a reason for feeder not being loaded properly after server is up?
What could be other possible consequences of the process I followed?

Gabor wrote: b) If you continue to do feeder rule changes, you may think of turning off the PersistentFeeders until you are done.

Does turning off and on of PersistentFeeder requires server restart?

Regards,
Deepak Jain