hyperion financial management: application design for performance

Copyright ©2013 by Chris Barbieri, Edgewater RanzalCopyright ©2013 by Chris Barbieri, Edgewater Ranzal

Hyperion Financial ManagementApplication 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 Profile1. Year2. Period3. View

System4. Value dimension,

includes currencies

User controlled5. Entity6. Account7. ICP8. Scenario

User defined9. Custom 110. Custom 211. Custom 312. Custom 4(*and more customs 11.1.2.2)


Application ProfileYear

● 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 DimensionValue 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

� Effect is multiplied when you consider the custom dimensions

� Parent accounts don’t lock

4- Net Income

3- Optg Income

2- Gross Margin

1- Sales

4- Optg Income

3- Gross Profit

2- Gross Margin

1- Sales

5- EBIT

6- Net Income


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 appsMedian +1 Std Deviation High

Accounts 1,444 2,915 7,491ICP Accounts With Plug 17 288 2,273Accounts With Data Audit 32 1,358 7,490Consolidation Rules 45%OrgBy Period 16%Currencies 25 57 150Custom1 181 3,219 23,897Custom2 72 2,374 20,484Custom3 46 909 5,681Custom4 19 182 1,199Entity Hierarchies 4 12 44Entities (unique) 672 4,352 21,199ICP Members 208 1,160 7,770Scenarios 12 29 81Process Management Scenarios

- 7 37

Scenarios Using Data Audit - 11 78Using Phased Submission ? 17%


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

� Density� Content

● Specifically: zeros● Tiny numbers● Invalid Records

“Metadata volume is interesting, but it’s

how you it that matters most”


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

Median +1 Std Dev Min Max

NumCubesInRAM 1,369 9,426 72 51,840

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

NumRecordsInLargestCube 53,089 167,085 2,508 593,924

Records per cube 1,352 15,537 24 91,418

Metadata efficiency 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 Loaded 0.9%

Calculated 9.4%

Consolidated 19.6%


Data Growth Up the Entity Hierarchy

Number of Entities

Top of hierarchy 1

Total in hierarchy 5,571

Base of hierarchy 2,980

Base Entity input 91records Base Entity

calculated 153records

Average Entity 178records

Top Entity16,829 records


Loaded, Calculated, and Consolidated Data

� Rough stats: median from 12 applications● +1 std deviation

MonthlyZeros

%Monthly Growth

Rules Growth

Loaded Records153,826

534,239 4.3% 3.3%

Loaded + Calculated Records

349,360 717,570 22.5% 2.7% 2.0

Consolidated Records

62,090 142,432 8.7% 3.2%


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 CompanyNumber of entities 11,321* 2 cubes: entity currency + contribution 11,321Non-USD entities 2,939add another cube for parent currency 2,939Entity_value cubes 14,260

Actual 2013, 2012 2Forecast1 2013, Plan 2013, TestForecast 2013 3Tests, etc. 10

Total Year_scenarios 15Total cubes 213,900Average records per cube 175Optimal NumDataRecordsinRAM setting 37,432,500bytes per record 120

Records * bytes converted to MB = MaxDataCacheSizeI nMB 4,284


Rules Timing


Data Density <> Calc Time

correlation between density and calc times� Most applications are rules bound

-

0.500

1.000

1.500

2.000

2.500

-

100

200

300

400

500

600

700

800

900

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

Sec

onds

Rec

ords

Average Rule Execution Time in Contrast with Data V olume


But Some Applications are I/O Bound

Time vs. Volume

050

100150200250300350400450

8382

0.83

820_

DF

R.F

R_N

BM

TO

TA

L_R

EG

ION

S.U

SU

SC

A.U

SE

ME

A.D

EA

P.C

NC

Z.C

Z_N

BM

DE

_NB

M.8

3704

FR

_NB

M.8

3519

TH

.838

99U

S.U

SG

OU

S.8

0808

BR

.835

4583

820.

8382

0_18

01O

TH

AP

.828

2883

820.

8382

0_18

51E

ME

A.B

ELA

.BR

US

.808

20A

R.8

3856

Sec

onds

0

10,000

20,000

30,000

40,000

50,000

60,000

elapsed

totalrecords

� HFM app server CPU is waiting for data


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

0 0.25 2.0 4.0 10.0

Seconds Per Entity Per Period


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


� 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

Consolidation Rules = “R”


Reference Application


Small but Constant Application

� Applied across multiple environments

0:00:00

0:00:43

0:01:26

0:02:10

0:02:53

0:03:36

0:04:19

0:05:02

physical physical virtual virtual physical physical virtual physical virtual virtual virtual virtual virtual virtual virtual virtual virtual

HFM lab A: Dev B: Dev C: Dev K: FIT D: QA Ranzal:dev

L: Stage K: dev T-61laptop

E: non-prod

F: prod T-410laptop

G: Dev H: Dev H: prod I: prod

Full Rules

Blank Rules

Target


Chris [email protected]

Needham, MAUSA

+1.617.480.6173www.ranzal.com

hyperion financial management: application design for performance

Technology

edgewater ranzalloaded

gross margin1

chris barbieri

currency

subcube

data

impact

entity