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 worlds largest HFM practice

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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
Copyright 2013 by Chris Barbieri, Edgewater Ranzal

Metadata

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

Designing HFMs 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.

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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
applications design
Daily is inadvisable

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

Consider number of UI clicks

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

System Dimension
Value Dimension
Can not directly modify this
<Entity Currency> points to entitys default currency
<Parent Currency> points to default currency of the entitys parent

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

Currencies
Dont add currencies you arent using

Sets of calc status records for (every entity * every currency)

Impact of loading metadata with entity or currency changes

Normally translate from the entitys currency only into its parents
currency
Beware of non-default translations

Impacted calc status

Data explosion
Adds to cycle time
Copyright 2013 by Chris Barbieri, Edgewater Ranzal

User Controlled Dimensions

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

Dont disable if you ever had journals on entity

ICP
Hidden dimension

Scenario
Number of tables
Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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 dont lock
Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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
Barbieri, Edgewater Ranzal
Using Phased Submission?Copyright 2013 by Chris17%

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

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

Whats 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
Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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
Copyright 2013 by Chris Barbieri, Edgewater Ranzal

Data Design
Metadata volume is interesting, but its
how you

it that matters most

Density
Content
Specifically: zeros
Tiny numbers
Invalid Records

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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

Cant identify
individual cubes,
harder to understand

Database
Analysis

Query DCE, DCN

tables and count

Easy for a DBA, see

all subcubes

Doesnt count
dynamic members,
includes invalid
records

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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%

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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%

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

Data Growth Up the Entity Hierarchy

Number of Entities
Top of hierarchy

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

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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%

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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
Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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
Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

40,000

30,000

20,000

10,000

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

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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
Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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 wont even exist

Studies show about 30% faster consolidation times

Must be enabled at app creation

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

Reference
Application

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

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

Copyright 2013 by Chris Barbieri, Edgewater Ranzal

virtual

virtual
I: prod

Chris Barbieri
cbarbieri@ranzal.com
Needham, MA
USA
+1.617.480.6173
www.ranzal.com
Copyright 2013 by Chris Barbieri, Edgewater Ranzal