Hyperion Financial Management Application Design for Performance

Hyperion Financial Management

Application Design for Performance

Chris Barbieri

Copyright ©2013 by Chris Barbieri, Edgewater Ranzal

Personal Background
Established HFM performance tuning techniques and
statistics widely used today
4+ years as Sr. Product Issues Manager at Hyperion
2001 HFM launch team 2001
Certified HFM, Hyperion Enterprise
B.S. Finance & Accounting, Boston College
MBA, Babson College
Established HFM Performance Tuning Lab at Ranzal
● Vice President of world’s largest HFM practice


Foundation of Performance
Focus first on single user
Metadata design as it
impacts performance
● Volume of members
● Impact of structures

Data
● Content
● Density

Rules
Environment

Metadata


Designing HFM’s 12* Dimensions
Application Profile
1. Year
2. Period
3. View

User controlled
5. Entity
6. Account
7. ICP
8. Scenario

System
4. Value dimension,

includes currencies

User defined
Custom 1
10. Custom 2
11. Custom 3
12. Custom 4
(*and more customs 11.1.2.2)
9.


Application Profile
Year
● No inherent impact on performance
● Can be increased after the application is built
● Impacts database table volume

Period
● Base periods comprise column structure of every table,
whether you use them or not
● Avoid weekly profiles unless it is key to your entire
application’s design
● Daily is inadvisable

View
● No impact, but only YTD is stored
● Other views are on-the-fly derivations
●

Consider number of UI clicks

System Dimension
Value Dimension
● Can not directly modify this
● “<Entity Currency>” points to entity’s default currency
● “<Parent Currency>” points to default currency of the entity’s parent
●

Anything above “<Entity Curr Total>” must be Parent.Child format

Currencies
● Don’t add currencies you aren’t using
●
●

Sets of calc status records for (every entity * every currency)
Impact of loading metadata with entity or currency changes

● Normally translate from the entity’s currency only into it’s parent’s
currency
● Beware of non-default translations
●
●
●

Impacted calc status
Data explosion
Adds to cycle time

User Controlled Dimensions
Entity
● Single biggest factor in consolidation time
● Avoid Consolidate All or All With Data on each
hierarchy
● Assign Adj flags sparingly
●

Don’t disable if you ever had journals on entity

ICP
● “Hidden” dimension

Scenario
● Number of tables

Impact of Account Depth

6- Net Income

4- Net Income

5- EBIT

3- Optg Income
2- Gross Margin

4- Optg Income

1- Sales

3- Gross Profit
2- Gross Margin
1- Sales

Effect is multiplied when you consider
the custom dimensions
Parent accounts don’t lock

User Defined Dimensions
Custom 1..4
● Think dozens or hundreds; resist thousands
●
●
●

If Thousands are necessary, 64 bit makes this possible
Rules remain a major factor in performance
UI click

● Avoid:
●
●
●

●

Employees
Detailed Products
Anything that is very dynamic, changing greatly from year to
year
One to one relationship with the entities

Configurable dimensions in 11.1.2.2

Metadata Efficiency Ratio
What does the average entity have in common with the
top entity?
● Measure re-use of accounts and customs across entities
top entity

base


Metadata Volume Study: 82 apps
Median

+1 Std Deviation

Accounts
1,444
ICP Accounts With Plug
17
Accounts With Data Audit
32
Consolidation Rules
45%
OrgBy Period
16%
Currencies
25
Custom1
181
Custom2
72
Custom3
46
Custom4
19
Entity Hierarchies
4
Entities (unique)
672
ICP Members
208
Scenarios
12
Process Management
Scenarios
Scenarios Using Data Audit
Using Phased Submission?
17%

High

2,915
288
1,358

7,491
2,273
7,490

57
3,219
2,374
909
182
12
4,352
1,160
29
7

150
23,897
20,484
5,681
1,199
44
21,199
7,770
81
37

11

78

Data


What’s a Subcube?
HFM data structure
Database tables stored by
● Each record contains all periods for a [Year]
● All records for a subcube are loaded into memory together

Parent subcube,
stored in DCN tables
Currency
subcubes, stored in
DCE tables

Take it to the Limit
Reports, Grids, or Forms that:
● Pull lots of entities
● Lots of years
● Lots of scenarios

Not so problematic:
● Lots of accounts
● Lots of custom members

Smart View
● Subcubes impact server performance
● Cell volume impacts bandwidth

Data Design
“Metadata volume is interesting, but it’s
how you

it that matters most”

Density
Content
● Specifically: zeros
● Tiny numbers
● Invalid Records


Data Volume Measurement
No perfect method
Method

How-To

Pros

Cons

Data
Extract

Extract all data,
count per entity

Simple, easy to see
input from calculated

Can only extract
<Entity Currency>

FreeLRU

Parse HFM event
logs

Good sense of
average cube, easy to
monitor monthly
growth

Can’t identify
individual cubes,
harder to understand

Database
Analysis

Query DCE, DCN
tables and count

Easy for a DBA, see
all subcubes

Doesn’t count
dynamic members,
includes invalid
records


Data Density Using FreeLRU
Number of applications reviewed
46
NumCubesInRAM

1,369

NumDataRecordsInRAM
NumRecordsInLargestCube
Records per cube
Metadata efficiency

Median +1 Std Dev

9,426

Min

72

Max

51,840

1,179,049 4,679,031 247,900 23,019,754
53,089

167,085

2,508

593,924

1,352

15,537

24

91,418

3.4%

12.2%

0.3%

39.7%


Loaded vs. Consolidated Zeros
What percent of the loaded data is a
zero value?
● <5% is reasonable
● Ideally, no zeros
● Watch ZeroView settings on scenarios

How many zeros are generated by
the consolidation process?
● Intercompany eliminations
● Allocations
● Empty variables

Consolidated 19.6%
Calculated 9.4%
Loaded 0.9%


Data Growth Up the Entity Hierarchy
Number of Entities
Top of hierarchy

1

Total in hierarchy

5,571

Base of hierarchy

2,980
Average
Entity 178
records

Base Entity
input 91
records

Top Entity
16,829 records

Base Entity
calculated 153
records


Loaded, Calculated, and Consolidated Data
Rough stats: median from 12 applications
● +1 std deviation

Zeros Monthly
Monthly
%
Growth
153,826

Loaded Records

534,239

Loaded + Calculated
Records
Consolidated
Records

349,360
717,570

62,090
142,432

4.3%

3.3%

22.5%

2.7%

8.7%

3.2%

Rules
Growth


2.0

Invalid Records
Type 1: Orphaned records from metadata that has
been deleted
● Member is removed from dimension_Item table, but not
from the data tables
● These can be removed by Database > Delete Invalid
Records

Type 2: the member still exists, but is no longer in a
valid intersection
● Most often from changing CustomX Top Member on an
account
● These cannot be removed by HFM, but are filtered out in
memory

So… How Much Memory Do I Really Need?
Calculation
Number of entities
* 2 cubes: entity currency + contribution
Non-USD entities
add another cube for parent currency
Entity_value cubes
Actual 2013, 2012
Forecast1 2013, Plan 2013, TestForecast 2013
Tests, etc.
Total Year_scenarios
Total cubes
Average records per cube
Optimal NumDataRecordsinRAM setting
bytes per record
Records * bytes converted to MB = MaxDataCacheSizeInMB


Company
11,321
11,321
2,939
2,939
14,260
2
3
10
15
213,900
175
37,432,500
120
4,284

Rules Timing


Data Density <> Calc Time
Average Rule Execution Time in Contrast with Data Volume
2.500

900
800

2.000

700

1.500
500
400
1.000

Seconds

Records

600

300
200

0.500

100
-

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

correlation between density and calc times
Most applications are rules bound

450
400
350
300
250
200
150
100
50
0
3820.83820_D
FR .FR _N B M
_R E GION S .U S
U S C A .U S
E ME A .D E
A P .C N
C Z .C Z_N B M
E _N B M.83704
R _N B M.83519
TH .83899
U S .U S GO
U S .80808
B R .83545
0.83820_1801
OTH A P .82828
0.83820_1851
E ME A .B E
LA .B R
U S .80820
A R .83856

S econds

But Some Applications are I/O Bound
Time vs. Volume
60,000

50,000

elapsed

totalrecords

HFM app server CPU is waiting for data

40,000

30,000

20,000

10,000

0

How Long Should Rules Take?
Total consolidation time in seconds,12 periods
● Consolidate All With Data for consistency, reliability
● Fastest of three consecutive runs

Divide by 12 periods and total number of entities
● Descendants inclusive of POV parent

Seconds Per Entity Per Period
0 0.25

2.0

4.0

10.0


Rules Impact Ratio
Total consolidation time with
rules
Divided by time with Blank
Rules
Typically 2- 5 times
More than that is an
opportunity for improvement

Consolidation Rules = “R”
Ideal for simple applications that do not need
consolidation rules
Skips writing [Proportion] to the database
● Smaller DCN tables
● If no [Elimination], [Parent Adjs] or [Contribution Adjs]
the DCN tables won’t even exist

Studies show about 30% faster consolidation times
Must be enabled at app creation


Reference
Application


Small but Constant Application
0:05:02

0:04:19

Full Rules
0:03:36

Blank Rules
0:02:53

0:02:10

Target

0:01:26

0:00:43

0:00:00
physical physical virtual

virtual physical physical virtual physical virtual

virtual

virtual

virtual

virtual

virtual

virtual

HFM lab A: Dev

C: Dev

T-61
laptop

E: non- F: prod
prod

T-410
laptop

G: Dev

H: Dev H: prod

B: Dev

K: FIT

D: QA

Ranzal: L: Stage K: dev
dev

Applied across multiple environments

virtual

virtual
I: prod

Chris Barbieri
cbarbieri@ranzal.com
Needham, MA
USA
+1.617.480.6173
www.ranzal.com

Hyperion Financial Management Application Design for Performance

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Hyperion Financial Management Application Design for Performance

Similar to Hyperion Financial Management Application Design for Performance (20)

More from Alithya

More from Alithya (20)

Recently uploaded

Recently uploaded (20)

Hyperion Financial Management Application Design for Performance