Feeder took 20 min to save. Can we reduce it?

[Paul-TM1]

Hi Gurus,
I have a feeder for a rule to escalate rate to future months and the rule took about 20 min to save. The model has no data and I am guessing it must be something with the feeder. Can some tell me how I can debug the feeder?

Code: Select all

SKIPCHECK;
['Rate']=N: IF 
	(
	ATTRS('Version', !Version, 'Live') @= 'Y',
		If(			DB('InfoRate',!Employees, 'Actual', !Months, 'ActualRate') = 0,			
					DB('InfoRate',!Employees, 'Forecast', ATTRS('Months',!Months, 'PrevMonth'), 'Rate')		
		, Continue)	
	,continue
	);
FEEDERS;
['Rate'] =>  DB(If( ATTRS('Version', !Version, 'Live') @= 'Y', 'InfoRate',''),!Employees,'Forecast', ATTRS('Months',!Months, 'NextMonth') ,'Rate') ;

Thanks,
Paul.

[ascheevel]

I'd take the IF statement out of the feeder and instead put your "live" versions into a consolidation and put the consolidation in your area statement of the feeder like below.

Code: Select all

['Rate', 'Live Versions'] =>  DB('InfoRate',!Employees,'Forecast', ATTRS('Months',!Months, 'NextMonth') ,'Rate') ;

[Steve Rowe]

The other thing to consider is the use of the next month attribute, looking at the other dimensions this would seem to be a combination of year and month.
This means that the feeder will feed forward recursively, so a single input will feed forward to all future periods. A fed cell will trigger an onwards feeder.

This will likley blow the feeder stack and you will see some errors in the message log, depending on the version you are on this could make the cube behave in unusual and broken ways.

I'm also suspicious of your statement that there is no data in the cube. If there is no data in the cube then the feeder won't fire when the rule is saved and therefore no time penalty incurred. According to my understanding the 20 min can't have come from the feeder if there is no data in the cube (and I suppose no feedeer flags persisting in the cube due to repeated attempts at writing the rule). Are sure there was no other activity on the server that could account for the long rule save?

[Paul-TM1]

Thanks for the reply steve.
Sorry, one mistake in my earlier statement.
There is rate populated already (other than rate, almost nothing else is populated) and the projection is for about 10 years. I removed the feeder and restarted which took like 50 secs to start the server.
Is there any way I can see what is causing is causing the latency? Any other ideas?

Thanks,
Paul.

[Steve Rowe]

Pretty sure it will be the next month nature of the attribute rolling forward, bare in mind that when the feeder compiles every data point will feed every month in front of it not just the next month.
The act of feeding a cell triggers feeders in that cell
So you have some very long feeder chains taht are being triggered repeatedly.


If you can't live with the long compile time then it's hard to say what the correct approach would be without a bunch more info but it's going to boil down to
1.Continue using rules but refine / redesign the functionality. For example maybe only have active months feed.
2. Stop using rules and use a TI to do the work.

I'm off for a pint!

[declanr]

Just to add a different spin/idea.

It's a rate so do you actually need to feed it?
Feeding gives you 2 benefits, 1 is that you can consolidate the results up - since it's a rate you don't need that. The other is that it allows you to zero suppress.

Even if you don't feed the cells, they still contain the correct rate and it can be used in further calculations.

Rates in general are something that can cause huge overfeeding, by their nature you tend to have a rate in every possible intersection. But a rate is only important when there is something to multiply it by (e.g. hours worked etc.)

[lotsaram]

Just to add a different spin/idea.

It's a rate so do you actually need to feed it?

I would second what Declan said but emphasise more you don't need to feed rates. Period.

Feeding from a modeling perspective serves one purpose only and that is to enable consolidation of values which are determined by calculations at the leaf level. Since you don't consolidate rates they don't need to be fed. You can use the rate as a multiplier in another leaf calculation and it will still calculate the correct result without being fed.

(Yes feeding can also serve a purpose to see onlyrelevant elements when using null supression in a view. But this is really a cosmetic usage and doesn't influence the accuracy of calculations.)

[MarenC]

I would second what Declan said but emphasise more you don't need to feed rates. Period.

I thought if they are not fed then they would not be available in TI source views either?
What if you want to copy rates from version to version? If they are not fed how would you create a view of them to do the TI copy?

Maren

[lotsaram]

I thought if they are not fed then they would not be available in TI source views either?
What if you want to copy rates from version to version? If they are not fed how would you create a view of them to do the TI copy?

Yes also true. Given in this case there seems to be just a single "live" version for the rate which is then used in all other versions so there would be no reason to copy it. But say you did want to copy unfed rule values to a data input "stet version" then you would have to either not have zero supression in the source view or else process a view with a fed measure or data input measure and then do CellGetN/CellGetS to lookup non-fed rule values before sending the values shoewhere else. So yes definately not as simple (but still also definately not worth feeding something that doesn't need to be fed for this reason).

[Paul-TM1]

Thanks everyone for the responses. Yes, I now understand why rates need not be fed. I will take these ideas. There was rate data feeding for over 10 years and it also consumed about 25GB memory.

Thanks again,
Paul.

[Mark RMBC]

Hi,

I am struggling to see how a TI process wouldn't be more logical than a unfed rule in the case of rates?

regards,

Mark

[Wim Gielis]

Hi,

I am struggling to see how a TI process wouldn't be more logical than a unfed rule in the case of rates?

regards,

Mark

Because the percentages, at whatever level in the dimensions, need to be calculated in real time ?

[Mark RMBC]

Hi Wim,

Because the percentages, at whatever level in the dimensions, need to be calculated in real time ?

Rates in my experience are pretty static, but maybe I need to get out more!

regards,

Mark

[lotsaram]

Hi,

I am struggling to see how a TI process wouldn't be more logical than a unfed rule in the case of rates?

regards,

Mark

I wouldn't see it as real time evaluation of the rate more it is a trade-off decision between memory optimization vs. runtime performance optimization. The benefit of rules is that they calculate only on demand and otherwise sit dormant not consuming any resources (especially if not fed). The drawback is rules are 2 orders of magnitude slower to consolidate than pure data.

Depending on how the rules are written the drawback with using TI to populate rates would be the all the intersections where the rates need to be populated to, possibly making the cube significantly denser and consume significantly more memory. Classic TI vs. rules trade-off.

[tomok]

Hi,

I am struggling to see how a TI process wouldn't be more logical than a unfed rule in the case of rates?

regards,

Mark

Because the percentages, at whatever level in the dimensions, need to be calculated in real time ?

This depends on the purpose of "Rate". If Rate is the result of a calculation and needs to be reported at all levels of the cube then yes, it needs to be fed so that it doesn't disappear when zero suppressed. If Rate is not the result of a calculation but instead is a driver of another calculation (which is my interpretation of the OP's situation) then it doesn't need to be fed at all. There are plenty of other ways to make sure the Rate is shown on reports so that you don't have to populate a zillion cells with it and then feed it. This design was likely done by a consultant who basically had a rudimentary knowledge of feeders and no real experience around the effect they can have on performance when not completely thought through.

[Wim Gielis]

I fully agree Tom