TM1 Forum

Hi All
I stalled TM1 9.5.1 and testing on its new feature. One feature still not understand. According to document guide said that

"To improve reload time of cubes with feeders, set the PersistingOfFeeders configuration parameter to true (T) to store the calculated feeders to a .feeders file"

"When PersistingOfFeeders=T, and a cube with rules is saved, the feeders are stored along side the cube data in a .feeders file. The cube files are called cube-name.cub and cube-name.feeders"

I added parameter PersistingOfFeeders = T in .cfg file. After start server, I don't see any objects in .feeders file so I'm not sure whether the message above means to have feeders in .feeders file as my understanding or it just get start time improviing from 9.5 version???


Thanks

Sounds like a bit of cool functionality. I haven't seen it yet.

This might well be a bit too obvious, but I have to ask anyway - have you actually got any rule files with feeders in them in your test environment? And have you done a server restart, or just a server start? In order for there to be feeders to save it'll have to create them first time round.

Martin

It appears the TM1 documentation leprechaun is still on the payroll
The correct CFG parameter is PersistentFeeders = T
From some further testing we have done, they work, but conditional feeders aren't handled properly.

I'm not sure I get the point of this...What do we get that we don't have now? Is it just improved start times? I can't see how it's useful for a running server.
Cheers,

Effectively the feeders are cached on disk as opposed to being recomputed on startup. I tested with a copy of a fairsized client system and startup came down from hours to minutes.

Shame about conditionals though.

Steve Rowe wrote:I'm not sure I get the point of this...What do we get that we don't have now? Is it just improved start times?

Don't want to just echo David but in essence yes, yes & yes! Usually the bulk of server load time is processing feeders as opposed to loading data which TM1 does very efficiently. As persistent feeders are loaded into memory just as cube data a server can load much more quickly. Once the whole model is in memory then there is no difference. Of course it's not going to be applicable for all situations but it's quite a brilliant idea, you wonder why it took this long for someone to come up with it.

Check this out:

http://publib.boulder.ibm.com/infocente ... sp?lang=en

Thanks for you guys replies. I tested starting on moderate size server and it came up real faster. I'm not sure what Divid said it doesn't handle properly with conditional feeders it does means feeders for IF condition will not be kept in feeder file?

With conditional feeder code like: If you have persistent feeders, a restart won't turn on or off the feeder which the flag cube controls. You have to delete the .feeders file to force the change.

When do we take the hit for the creation of the feeder file? When the server is shut down or rules saved or data loaded or on demand. Does it take very long?

Cheers for the info btw, looks interesting and an apparently simple change for a larger return.

Feeder files are created when the server is run up. From my tests I didn't see an additional overhead for the creation.
I think that rule saves don't update the feeder file, but on the next restart, the server compares the date of the RUX and the .Feeders and if the RUX is newer, rebuilds the .Feeders.

David Usherwood wrote:Feeder files are created when the server is run up. From my tests I didn't see an additional overhead for the creation.
I think that rule saves don't update the feeder file, but on the next restart, the server compares the date of the RUX and the .Feeders and if the RUX is newer, rebuilds the .Feeders.

That wasn't my understanding from reading the documentation. The .feeders file is saved when a data save is actioned. My interpretation is that on server start-up feeders are re-evaluated for a cube only if a .feeders file is absent and a .rux file is present (hence the recommendation to periodically delete all .feeders files prior to server restart to ensure no overfeeding.) The feeder file might be saved during rule compile also but not sure on that one. Hopefully David and I will both be enlightened on this topic by the end of next week.

Hi,

If I don't get it wrong, then the Persistent Feeders will only decrease the server startup time. But once all cubes and feeders are loaded, the Persistent Feeders won't affect anything. Am I right?

comma wrote:Hi,

If I don't get it wrong, then the Persistent Feeders will only decrease the server startup time. But once all cubes and feeders are loaded, the Persistent Feeders won't affect anything. Am I right?

Yes. Well at least almost, ... 95% right.

Once fed a cell stays fed (indefinitely). If data in the cube that was triggering feeders is zeroed out the feeders persist in that server session. In the pre 9.5.1 world feeders would be reprocessed each time on server start-up so the fed portion of the cube would be correct based on current leaf data. However when the .feeders file is saved "dead" feeders are not removed. Hence it is possible that when the server is reloaded there will be some residual over-feeding which could affect performance. This is why the manual suggests to periodically delete the .feeders files and reprocess feeders.

Hi,

I'm thinking about implementing that "PersistentFeeders" functionnality in a 9.5.2 application.

Before beginning more tests, I just would like to clarify two points:
-When an instance is started, if you load some data via TI, are the .feeders files automatically/instantaneously updated?
-I've read in that post that it doesn't work if there are some conditional feeders. Do you confirm that point?

Thanks in advance

Catherine wrote:Hi,

I'm thinking about implementing that "PersistentFeeders" functionnality in a 9.5.2 application.

Before beginning more tests, I just would like to clarify two points:
-When an instance is started, if you load some data via TI, are the .feeders files automatically/instantaneously updated?
-I've read in that post that it doesn't work if there are some conditional feeders. Do you confirm that point?

Thanks in advance

Catherine

From what I have seen, .Feeder files are only generated when you do a SaveData, or when you shut the TM1 Service down.

From the point of view of conditional feeders, unfortunately TM1 always has a few problems with conditional feeders, There is a TM1S.CFG file option ReevaluateConditionalFeeders, which doesn't always work. However, without PersistentFeeders, at least when you re-start the service any conditional feeders will get evaludated correctly. If you have Persistent Feeders, then even at server start up the conditional feeders won't get re-evaluated because it doesn't evalualte the feeders, it just loads the feeders from the .feeder file, and it won't have the feeder in there if it didn't exist in memory at the time that the .feeder file was created.

It is worth expanding on what is a conditional feeder. The usual example is where you have an IF condition on the Right Hand Side of the feeder. However, we had a case where (from a third party design) we had data being loaded against a Date element in the Date dimension and the Day element in a Periodicity dimension. This was then copied across to a YTD element in the Periodicity dimension against the same Data element, by a rule which calculated the YTD position by summing the relevant elements of the Date dimension crossed with the Day element in the Periodicity dimension. Since data in any element of the Date dimension could give rise to a YTD later in the year, they fed from Day,Date to YTD for All Dates in the Year. To avoid over-feeding they only added a weeks work of Dates at a time. The problem we found when using Persistent Feeders was that if we had say Date elements to 1st Feb 2011, and we then added a weeks worth of Dates so we now had Dates to 8th Feb 2011, then the Dates from 2nd Feb to 8th Feb 2011 never got fed, for YTD, because feeders did not get re-evaluated when the service was re-started. Effectively we had a subtle type of conditional feeder.

The service started quickly with the .feeder files - it only took around 15 minutes. However, there was little point in it starting quickly if the YTD numbers were wrong

The only way to get the feeders to be re-evaluated was to delete the .feeder files and re-start the service. However, then the service took 6 hours to start.

Another issue we had was with .feeder files getting deleted, when the TM1 service was re-started at the weekend because the system said that a .feeder file was earlier than the date of a cube. (This is why I believe that .feeder files are only updated when there is a SaveDataAll or Server Shutdown. This is how TM1 checks that the .feeder file is in step with the .cub file)

Even if the feeder file on only one cube is out of date, it deletes the .feeder files from all cubes.

I eventually traced this to the fact that we had some cubes that had no internal feeders, ie no feeders to the cube itself. They only had feeders to other cubes. When the Save Data happened, it still seemed to create a blank .feeder file for the cube, even though it didn't need any feeders since it had no rules in itself that needed feeding. However, the next time the SaveDataAll happened (which we did nightly) then, because there were no feeders, it did not update the .feeders file. Therefore, by the time the weekend came the .feeders file was last modified earlier than the ,cub file, and the system said that as one .feeder file was out of date on an minor cube, it deleted the .feeders files for all cubes, including the largest cube. We then had issues of the Service taking 6 hours to start, which then caused other problems with scheduled tasks failing etc.

I cured that problem by adding a dummy rule in the cube and a dummy feeder to it. Once the cube had a real rule that was being fed its .feeders file always got updated when the cube was saved.

Once I had finally cured the .feeders files getting deleted issue, I was able to prove that any sort of conditional feeders don't get re-evaluated with Persistent Feeders.

So Persistent Feeders could not reduce load times without compromising data quality in our semi-cdnditional feeders.

Without Persistent Feeders the service start up time of 6 hours was unnacceptable.

At that point I changed the design that the third party had implemented.

I removed the rule based calculation of YTD, and instead calculated YTD by consolidation. This meant that there was no need for any feeding. This meant that there was no need for Persistent Feeders.

The Service now starts in 20 minutes for a 90GB Cube, which is only a little slower than the situation for the original design with Persistent Feeders. Reports also run up to 4 times faster.

Therefore if you are considering using Persistent Feeders to speed up start up time, I would advise you to first look at your current feeders to ensure that there is no over-feeding, and look at your design to see if there is another way to avoid feeding altogether, eg can things be calculated by consolidation instead of by rules.

Other points mentioned above are that, with Persistent Feeders once a cell is marked as fed, it will always be fed, even if the cell feeding it is now a zero. That is why you would need to do a scheduled deletion of .feeders files anyway, otherwise over time you could end up with a lot of over-feeding, depending on your data model. You will then need to take account of the fact that at some times you will need to allow a lot longer for your service to start up.

Another downside of Persistent Feeders is that while they can improve start up time,there is a time penalty at shut down time, as writing the .feeders file does take time. If you are looking at a weekly shutdown and re-start to clear down memory, the time may be extended due to the extra time to shutdown. Having said that, if you don't have conditional feeders and you are OK to use Persistent Feeders, then the shutdown and start up time will still probably be faster than without Persistent Feeders.

You also need to be careful about disk space. On a 2GB cube, we had a 28GB .feeders file.

You also need to be careful when developing. If you are changing rules and feeders to reduce over-feeding, you can never be sure if you have gone too far and are now under-feeding, because the feeders from the over-feeding will remain in the .feeders file. Therefore when developing I would advise you to have Persistent Feeders turned off. Since your are generally developing on cubes with smaller volumes of data than production, this shouldn't be too much of a problem.

Overally, I don't think I have worked on many systems that don't have some form of conditional feeding, so in practice I think the number of cases where Persistent Feeders can be used will be pretty limited.

Regards

Paul Simon

Good to see you around the forum again, Paul.
I agree with almost all of what you say about persistent feeders. Two small points:

• I've just run up a brand new server with PF on and the .feeders files have been created;
  The _one_ situation they are _really_ useful are demos and PoCs. It's great to be able to shut a server down, travel to a client/prospect, and run it up in seconds.

Hi Paul and David,

Many thanks for sharing your experience on the subject.

I don't want to provide the users bad quality data so I think I'm going to give up this option.

In fact, I don't have a problematic of reducing load times (it is true that it reduces my load times from 5 minutes to a few seconds but...). My initial problematic is a problem of instance crash at startup, when loading feeders.
(http://www.tm1forum.com/viewtopic.php?f=3&t=6624)

So using PersistentFeeders is the workaround suggested by IBM

We are going on investigating the crash on our side, and it seems linked to the hardware, but it is very difficult to find out exactly what is wrong.

I don't think persistent feeders is as gloomy as Paul and David make out. I think most of the time and in most situations it (can) work very well. Not all models have conditional feeders, and even if you do the conditions don't necessarily change all the time and require reevaluation.

The one really annoying thing about persistent feeders is when they fail on a large rule heavy model and your server takes hours to load when you have become accustomed to minutes or seconds. The test of a .feeders file being older than a .cub file really isn't a very good one as there are situations where the cube file will be updated and saved but the feeders aren't, such as:
- small cube or string cube without any skipcheck or feeders (this produces a 1KB .feeders file which typically isn't ever updated unless the rule is saved)
- cube that feeds another cube(s) but has no internal rules or feeders of its own (the scenario noted by Paul)
- situation where a cube has data updates but the data updates don't generate any new feeders (cells updated that have already fired feeders or areas of the cube that simply don't feed anything)

The really annoying thing is that when such feeder validation fails it is invariably on some tiny lookup cube where the feeders could have been reprocessed sub second. The problem is that ANY missing .feeders fuile of a cube with .rux or ANY .feeders file older than the corresponding .cub file will trigger automatic deletion of ALL feeder files and a "traditional" server restart. Why IBM can't build a simple forced save of the corresponding .feeders file every time a cube file is saved to avoid this is to me unfathomable. This would seem to be a simple fix, but ultimately there should be some more sophisticated management where it is possible to tell the server for which cubes it is acceptable to skip the feeder file validation.

I say use the feature! But just be prepared for it to not work once in a while (or to not work with monotonous regularity depending on the specific model.)

Read all the posts here and I'm just interested how may people are actually using Persistent feeders in prod, what are your experiences?

I'm considering turning it on but not sure if I'm prepared for rules /feeder to not work (once in a while or with with monotonous regularity)

In our user group it sounds like most people have played it safe.