Persistent Feeders in TM1 9.5.1

[lotsaram]

This is a pretty old thread and most if not all of the comments relate to 9.5.1. IBM have sorted out most if not all of the issues around saving of feeder files and the timestamp evaluation vs cube file. Assuming you are using 10.1 I would see absolutely no reason whatsoever not to use persistent feeders. The advantages of quicker server startup are clear. There may be some models with tricky conditional feeding based on values in lookup cubes but these are rare and anyone with such a model would know about it. For everyone else it is a switch that should be on by default.

[jameswebber]

Thanks heaps Lotsaram

[Duncan P]

However - before you turn on the switch make sure you have enough disk space. It's a bit of a beggar to get to the end of a 10 hour server load to find that it failed with "Out of disk space" trying to save its feeder files. Been there.

[garry cook]

Just be careful of http://www.tm1forum.com/viewtopic.php?f=3&t=9023 if you're on 10.1 base version.

[jameswebber]

Thanks heaps guys,
That is a tricky one Gary. I have FP1 installed in CE 10 so hopefully that wont be an issue.
(Had to goto FP1 to fix dynamic subsets)

[iansdigby]

We tried the persistent feeders feature and found it reduced our server load time from 35 mins to about 5 mins but that it frequently failed for obscure reasons.
When it failed we would be back to waiting 35 mins (whilst dodging flak from users) to get it up and running again.
The reasons for the failures are obscure but we vaguely recognise the scenario described above where rules files contain inter-cube feeders but no internal ones.

There has been a good spinoff though: as we loved the short load times but couldn't get PersistentFeeders working reliably, we turned it off and tried other approaches to reducing load time, finding that there was lots of inefficiency in our cubes. Indeed, I believe we will have gotten our load time down to 5 minutes anyway soon, via a combination of:

- auditing cubes and removing historic data that non-one actually needs;
- 'freezing' historic data in cubes so it is no longer rule-calculated and thus needs no feeders - resulting in perhaps up to 80% less feeding;
- considering whether calculated data needs consolidating at all and if not, removing unnecessary feeders thereto. (e.g. a prime costs cube whose data is only ever read at the N level)
- reviewing the message log to target cubes that take longest to load their feeders.

Regards, Ian

[George Regateiro]

We tried the persistent feeders feature and found it reduced our server load time from 35 mins to about 5 mins but that it frequently failed for obscure reasons.
When it failed we would be back to waiting 35 mins (whilst dodging flak from users) to get it up and running again.
The reasons for the failures are obscure but we vaguely recognise the scenario described above where rules files contain inter-cube feeders but no internal ones.

We had this problem alot in the 9.5 area, but all of our random invalidation issues have been solved in the 10.1 version. We spent alot of time with IBM on this since it continually bit us because of BI related crashes and constant invalidation. If you have upgraded it may be worth another look since outside a few quirks around conditional feeders there is almost no reason to not use persistent feeders.

[iansdigby]

I have also noticed on one occasion that, despite TM1 reporting that it discovered a mismatch on a .cub vs .feeders timestamp, and would therefore delete and re-create all feeder files, this did not actually happen. .feeders files still existed on the server 4 hours later with timestamps from 10 days earlier.

Despite all these niggles, and given the absence of any or many conditional feeders, I still think it's a great feature.

Ian