This content has been marked as final. Show 11 replies
I just checked my calendar to see if it was April 1, it's not. :-)
Bear with me as I understand it is a requirement on your end, but what in the wrold do you need that for? Perhaps talking about that out loud will lead to an alternate solution that you can propose to get your requirement changed?
Are all of these entities at the same level? (that would be worse) If they are all at one level, it would help to add some parent entities and subdivide them.
What are the specs on the 4 App Servers? (most interested in RAM)
How many concurrent users do you have?
It sounds to me your best bet here is to max out your RAM in the app servers and made the appropriate registry settings to ensure you are taking use of the memory. Perhaps having more memory per app server will help it load/cache the data it needs. I would take a look at page faults on these machines and cache hits/misses to get an idea of what the memory situation is.
Thanks for the quick response.
The reason for this requirement is that we have a Opco with a legacy Enterprise application which has been around for years and their design currently works well for them.
The 180k entitiy members are comprised of the business unit, geo location, part number and prodline. There are many alternate hierarchies and not all base members. Once we can bring accross the entities, load data and reconcile, we can they design the application using Custom 1 - 4 for geo location, PN and prodline. Unfournately, we need to bring it across as is to understand the conceptual concept we propose on using.
Currently, we have allocated 4GB per server with the ability of expansion. Before adding addtional system resources, i want to make sure that having 180k entities is achievable.
Sorry, forgot to inlcude the only users in the system are me and another developer.
After reviewing the performance documents / subcube architecture documents, I see nothing that indicates an actual set number.
Looking at the database strucuture, the ItemID field for the Entity tables (i.e. unique ID field) is a 4 byte integer which has a max value of over 2 billion.
Hypothetically speaking, there shouldn't be an issue here other than it's crazy. :-)
Since this is just a dev type environment, I'd almost think you want one App server with as much RAM as you can throw at it. (update registry settings accordingly)
One other suggestion : Ditch the rules files. (or at least everything that you absolutely don't need) [Assuming there is one]
Other suggestion : Make multiple applications and subdivide the data/entities that way. Combine the data and then extract and load it all to the final application for everything?
Thank you very much for the explanations and feedback. I completley agree with you in the sense that it's crazy to have this many members. Unfortunately, with this being a new customer we need to make them happy! :)
Can you tell me where you found the sub-cube document? I had this for V4.02, however I haven't found a recent version.
Thanks again for your help!
There is no specific limit to the number of entities in an HFM application.
That said, you are proposing a deeply problematic application. For most applications the consolidation time equates to between 0.25 and 2.0 seconds per entity, per period. using this rule of thumb, you are looking at between 12 and 48 hours to consolidate each period. Given typical data volumes, you may create a database that exceeds a few hundred gigabytes (or about 10-20 times normal).
I highly recommend revisiting the application design before going down this road.
Try these documents out for some frame of reference :
Performance Tuning Guide
Support.Oracle.com -> Hyperion Financial Management (HFM) Performance Tuning Guide, Fusion Edition [ID 1083460.1]
Subcube architecture Guide
I have a local copy, but cannot find it on-line at the moment, but the 'newer' version was :
"Hyperion System 9 Financial Management - Subcube Architecture April 2006"
From what I recall, it didn't change significantly from the HFM 4 document. This document is also the one I just looked over when I stated it didn't make any mention about entity limits.
Hope that helps.
Thanks for the feedback Chris. I will definately share these responses with the team.
Would this application design perform better under the file based Enterprise system oppossed to HFM? I have very little experience with Enterprise and I'm trying to understand how they are running with this design for so long and not suffering from majory system performance issues.
I had a feeling the document wouldn't have changed much.
Thanks again for your feedback!
"Re-platforming" from Enterprise to HFM without redesigning the application and supporting processes is a mistake, leading not only to performance concerns we've already expressed, but also an unhappy customer who would have missed out on key functionality of HFM. Look hard at the entities and I'm certain you will see other dimensions living in the entity dimension that should be moved out into the custom dimensions in HFM. This is apparent in naming patterns, often visible by segments of the label separated by underscores. I've worked with Enterprise for 15 years now, and HFM since its inception in 2001, and I encourage you to not allow the customer's content with the current design to lead to a disaster in HFM in the future.
Thanks for that great explanation Chris. Much appreciated....