2.0.9.16 Rule save time dramatically less - Feeder calcs?

[JohnO]

We believe this is working differently to how it used to and we think this has appeared in either .15 or .16.

We have many cubes with inter cube feeders, conditional feeders etc.

On server startup the feeder process time for a particular cube is approximately 30 minutes. This has not changed with the latest versions.

If we perform a simple rule change for this cube it used to take 30 minutes to fully save (including processing feeders)
Now if we perform a simple rule change it is performing the save in about 2 minutes (in the log it says it has processed feeders). On a server restart it then takes 30 minutes.

Could it be performing a delta computation on the feeders or perhaps it's not properly calculating feeders?

Any thoughts?

[Steve Rowe]

At some point the rule compiler became intelligent enough to know that you had not changed the feeders and so does not recompile them. This means you can change rules quickly and is generally regarded as a good thing...

You do need to take care though as it's probably possible to dream up a use case where a change to the rules would require the feeders to recompile.

[JohnO]

At some point the rule compiler became intelligent enough to know that you had not changed the feeders and so does not recompile them. This means you can change rules quickly and is generally regarded as a good thing...

Thanks Steve

The last test case I performed was the removal of a feeder. Perhaps adding a feeder might take longer. Might need to test further.

John

[gtonkin]

Noticed this parameter in the TM1S.CFG - may be worthwhile checking/reviewing. Default is True though.

SaveFeedersOnRuleAttach
When set to False, postpones writing to feeder files until SaveDataAll and CubeDataSave are called, instead of updating the files right after rules are changed and feeders are generated at the Planning Analytics database start time.

[JohnO]

Noticed this parameter in the TM1S.CFG - may be worthwhile checking/reviewing. Default is True though.

SaveFeedersOnRuleAttach

Thanks George, good idea. But it's not in use and we are not using persistent feeders.

[lotsaram]

Noticed this parameter in the TM1S.CFG - may be worthwhile checking/reviewing. Default is True though.

SaveFeedersOnRuleAttach
When set to False, postpones writing to feeder files until SaveDataAll and CubeDataSave are called, instead of updating the files right after rules are changed and feeders are generated at the Planning Analytics database start time.

I hadn't ever heard of that one. But I would assume from the documentation that feeders will still always be processed and this parameter only influences the actual saving to disk of the .feeders file. (Note: when saving a rule, the server is already smart enough to only compile feeders if there has been a change to the feeders section, so if just working on the calculations themselves then rule compilation woudl normally be very fast anyway if only calculations have changed and not feeders).

[lotsaram]

We believe this is working differently to how it used to and we think this has appeared in either .15 or .16.

We have many cubes with inter cube feeders, conditional feeders etc.

On server startup the feeder process time for a particular cube is approximately 30 minutes. This has not changed with the latest versions.

If we perform a simple rule change for this cube it used to take 30 minutes to fully save (including processing feeders)
Now if we perform a simple rule change it is performing the save in about 2 minutes (in the log it says it has processed feeders). On a server restart it then takes 30 minutes.

Could it be performing a delta computation on the feeders or perhaps it's not properly calculating feeders?

Any thoughts?

Steve has already pointed out that rule compilation doesn't include processing feeders unless feeder statements have changed. But assuming you are changing feeders or are using the CubeProcessFeeders function then this difference could be due to MTQ. Do you have MTFeeders or MTFeeders.AtStartup in the tm1s.cfg file? The documentation says MTFeeders is false by default, but it wouldn't be too surprising if the default value had been switched to true. IBM do tend to do this (conservative approach, initial default value preserves old behaviour, default value changes to new behaviour once feature is established and proven) and the documentation rarely keeps up.

[JohnO]

[/quote]
Do you have MTFeeders or MTFeeders.AtStartup in the tm1s.cfg file?
[/quote]

No and we are not using persistent feeders. We have a lot of conditional feeders.