Rule Save Takes too long

[mce]

Hi,

For a big cube in TM1, where we have few pages of rule including feeders. However when making any single change in the rule takes about 15 minutes to save.
Is there any trick or recommendation to improve the Rule-Save performance to make it quicker?

Thanks in advance for all replies.

Regards,

[kielmc]

When tweaking rules on cubes with heavy data and feeders, I like to strip off ALL the feeders until I get the rule calculation just right. Then when I get the rule they way I want it, I put the feeders back in.

[kpk]

It is better to test the new rules in a dev environment and only save the last tested rule in the productive environment when the system is not used very much.
You can also do it automatically during the night with RuleLoadFromFile(Cube, TextFile); function.

If you have enough server license you can set up a dev server really fast, if not then you can do it with a Perspectives and Local server.

In the dev environment you can delete a huge part of the data to make the test faster.

[kielmc]

It is better to test the new rules in a dev environment and only save the last tested rule in the productive environment when the system is not used very much.

Really? Feeders persist for the entire length of time a server is "up"...and now with the persistent feeders option in 9.5 even longer. So removing the feeders from the rules file doesn't actually take them out of play, it is simply a way of telling TM1 not to reprocess them when you save a rule file, which is what takes so long in the first place!

In the dev environment you can delete a huge part of the data to make the test faster.

I certainly agree that these rule changes should be taking place in a development environment, and that reducing the amount of data in a development environment will speed up the time it takes for feeders to be processed. However, there is a cost associated with doing this. I've all too often seem this tactic employed...develop on a server with very little data, get lightning fast performance, then deploy to production, add real data volumes and WHAM...TM1 performs horribly . I believe its best to be developing rules and especially feeders on a database with a full complement of data so that the true cost of each rule / feeder is recognizable immediately.

My two cents...hope its helpful : )

[kpk]

It is better to test the new rules in a dev environment and only save the last tested rule in the productive environment when the system is not used very much.

Really? Feeders persist for the entire length of time a server is "up"...and now with the persistent feeders option in 9.5 even longer. So removing the feeders from the rules file doesn't actually take them out of play, it is simply a way of telling TM1 not to reprocess them when you save a rule file, which is what takes so long in the first place!

You are right, a more accurate answer would be that "it depends":)
If you are the only user of the model or the system is not actively used then yes you can do it and you might not run too high risk with this approach.
But if you have a bit more users and an actively used reporting, forecasting system then testing and playing with rules in a productive environment is probably a bit more risky.
Yes, you CAN do it (and I also do it many times depending on the client, the model etc., although if you know that it takes 15 minutes to save a rule (as it was written in the original post)
then it is usually not best approach to test and play in the productive system.

In the dev environment you can delete a huge part of the data to make the test faster.

I certainly agree that these rule changes should be taking place in a development environment, and that reducing the amount of data in a development environment will speed up the time it takes for feeders to be processed. However, there is a cost associated with doing this. I've all too often seem this tactic employed...develop on a server with very little data, get lightning fast performance, then deploy to production, add real data volumes and WHAM...TM1 performs horribly . I believe its best to be developing rules and especially feeders on a database with a full complement of data so that the true cost of each rule / feeder is recognizable immediately.

I understand your point, although testing whether a rule works or not and testing a correct rule with a real (realistic) data volume can be 2 separate issues.
You usually need for both of them.
If it takes 15 minutes with real data volume (as I it was written in the original post) then you may save some time if you do it in 2 steps.
Of course it is your choice. You can do it in one step and many times that is the most efficient approach.

I like to strip off ALL the feeders until I get the rule calculation just right. Then when I get the rule they way I want it, I put the feeders back in.

Could work, but be careful with this approach since if you test without skipcheck on a cube which has 15 minutes rule saving history with skipcheck then you can easily start a really long lasting calculation if you (or any other user) try to test on C level elements.
Actually the first rule line I save in a cube is almost always the SKIPCHECK. I think it is better to plan, write and test rules and feeders hand in hand since they should work together.

"Is there any trick or recommendation to improve the Rule-Save performance to make it quicker (than 15 minutes)".

Yes:
1. you can save time on the prod server, if you dev and test in a separate environment and your users will be probably happier or at least not so angry:).
2. you can save time in the dev and test environment if you separate the functional and data volume test.
3. we have supposed until now that the rules are already optimized.
I have optimized many models in the last 10+ years and the start up time of the models (and/or saving/loading time of a rule) were many times reduced by 50-95%.
You can reduce overfeeding, you can find a better logic for rules or feeders and you can replace rule-calculated data with persistent values (e.g. for old versions, for old actuals), etc.
These steps could reduce the rule saving time also.

Kind regards,
Peter