HFM Performance Report

Oracle® Hyperion Financial

Management 11.1.2.1

Performance Report

Hyperion Financial Management 11.1.2.1 Performance Report Page 2

Oracle® Hyperion Financial Management 11.1.2.1

Performance Report

TABLE OF CONTENTS Executive Overview ......................................................................................................... 4

Introduction ........................................................................................................................ 4

Test Configuration ........................................................................................................... 5

Hardware Setup ........................................................................................................... 5

Tuning .............................................................................................................................. 6

HFM Application Servers .................................................................................... 6

HFM Web Server .................................................................................................... 6

Test Scenario ................................................................................................................. 6

HFM Application Details ..................................................................................... 7

LoadRunner Scripts .............................................................................................. 8

Results ................................................................................................................................... 8

Non-Consolidation Tests .......................................................................................... 8

Response Time vs. Load ...................................................................................... 8

Resource Usage vs. Load .................................................................................. 14

Consolidation Tests ................................................................................................. 18

Response Times ................................................................................................... 18

Resource Usage .................................................................................................... 19

Conclusion ........................................................................................................................ 21



Oracle® Hyperion Financial Management 11.1.2 Performance Report

EXECUTIVE OVERVIEW This document summarizes performance testing carried out for Oracle® Hyperion Financial

Management, a component of Oracle’s Enterprise Performance Management (EPM) System. These

tests used EPM version 11.1.2.1 running on Windows 2003 servers. They demonstrated the ability

of the software to support 1000 users and dozens of concurrent consolidations on a basic

configuration, as well as the ability to scale to even larger user loads.

INTRODUCTION Oracle Hyperion Financial Management is a financial consolidation and reporting application built

with advanced Web technology, but used and maintained by the finance team. It provides financial

managers the ability to rapidly close and report financial results, meet global regulatory

requirements, reduce the cost of compliance and deliver confidence in the numbers. With Oracle

Hyperion Financial Management—one of Oracle’s enterprise performance management

applications—you can improve your closing and reporting process and reduce internal control

risks. Financial managers move from the role of scorekeeper to one of business partner—

delivering financial analysis that supports strategic and operational management decisions. With

purpose-built features, Oracle Hyperion Financial Management is the cornerstone of sustainable

compliance frameworks and helps businesses comply with stringent reporting regulations.

Performance testing and capacity planning for enterprise applications such as Oracle Hyperion

Financial Management is a complex task. To demonstrate Hyperion Financial Management’s ability

to support large user populations while delivering quick response times, Oracle completed testing

of a scaled out system. The results of these tests prove the scalability of Financial Management and

also provide data which can be used for preliminary sizing estimates. This paper focuses on the

performance testing of Hyperion Financial Management only. Tuning of database and web servers

is out of the scope of this paper.


TEST CONFIGURATION

HARDWARE SETUP The configuration used for Financial Management consisted of seven servers as described below.

Server Processor Cores Memory Function

Workspace AMD Opteron 280 - Dual dual-core

at 2.41 GHz 4 cores 3.83 GB

Workspace,

Foundation

Services

HFM Web AMD Opteron 280 - Dual dual-core

at 2.41 GHz 4 cores 3.83 GB HFM Web Server

HFM App 1

HFM App 2

HFM App 3

Intel Xeon E5345 - Dual Quad –

core at 2.33 GHz

8 cores

each

12 GB

each

HFM Application

Servers

DB Server AMD Opteron 880 - Quad dual-

core at 2.40 GHz 8 cores 7.83 GB Oracle 10g RDBMS

Figure 1

Hardware Configuration

HFM App Server 1

8 cores x 2.33 GHz, 12 GB RAM

HFM App Server 2


HFM App Server 3


Workspace, HSS

4 cores x 2.41 GHz, 3.8 GB RAM

HFM Web Server


`

LoadRunner

Controller/Agent

Database Server


LDAP Server



The Oracle HTTP Server was installed on the Workspace server along with the Workspace Web

Application, Workspace Services and Foundation Services. The HFM Web Application was installed

on a separate, dedicated server. The HFM Application Server ran on three different boxes. A sixth

server hosted the Sun One Directory Server. The Oracle database ran on the seventh server. The

HFM Application Servers ran as 64-bit processes; all other components ran as 32-bit processes.

TUNING The following tuning adjustments were made to the system prior to running the tests described in

this paper.

HFM APPLICATION SERVERS HFM UI Configuration settings:

Number of Pooled DB Connections = 200

Registry Settings

MaxDataCacheSizeInMB – 4,000

MaxNumDataRecordsInRAM – 30,000,000

NumConsolidationThreads – 8

HFM WEB SERVER IIS

HfmAppPool Properties – No limits (i.e. boxes UNchecked) for:

Recycle worker processes (in Minutes)

Recycle worker processes (number of requests)

Maximum virtual memory (in Megabytes)

Maximum used memory (in Megabytes)

ASP

AspProcessorThreadMax="50"

TEST SCENARIO Client loads for the Financial Management testing were simulated using LoadRunner 9.5.

LoadRunner allows users to record browser actions into a file that can then be edited to add think

time, transaction definitions and parameters for substitution with random values. LoadRunner

records not only the HTTP requests made by the client, but also the data sent to the server. This

ability to record the network traffic is a requirement for testing Financial Management. Using

LoadRunner, Oracle developed a test scenario that included a list of host computers for clients, the

names of the test scripts and the number of simulated users running each script. The test scripts

were then run repeatedly for each simulated user until the defined test schedule terminated them.


The nature of consolidation transactions makes them resource-intensive and also causes them to

lock data for updating. This can have an impact on the performance of other activities if the servers

are overloaded or consolidations have locked data needed by other users. In order to more

accurately measure response times and resource usage for non-consolidation activities, separate

tests were run without any consolidation activities running concurrently. Additional tests were

then run purely with consolidations to measure resource requirements for those.

HFM APPLICATION DETAILS The Hyperion Financial Management application used for these tests is an actual application in use

by a large, global financial company. Several of the consolidations used in testing are quite large.

Table 1 lists the number of members in each of the application dimensions.

Table 1

Application Statistics

Dimension Number of Members

Scenario 18

Entities 2862

Account 31854

Value 18

Year 14

Period 4

Currencies 66

C1 1160

C2 68

C3 2

C4 63


LOADRUNNER SCRIPTS Eleven different LoadRunner scripts were prepared and user distributions were assigned as listed

in Table 2. Unique usernames were used for the virtual users and each was provisioned as a

typical user with a unique POV.

Table 2

LoadRunner Scripts and User Distribution – Non-consolidation

RESULTS

NON-CONSOLIDATION TESTS The first set of tests conducted focused on non-consolidation activities. Three tests were run, with

a single HFM Application Server, two HFM Application Servers and then with three HFM

Application Servers. The results of these tests showed that each HFM Application Server could

handle 300-350 users before response times exceeded acceptable limits.

RESPONSE TIME VS. LOAD Response times were measured using LoadRunner. LoadRunner replays communication from the

client to the server and measures the response time for the response to each communication. It

does not measure the amount of time needed for any client-side processing after the response is

received. This is acceptable for load and scalability testing since the focus is on how load affects

the server processes.

Activity % User

Distribution User Load

1 App Server User Load

2 App Servers User Load

3 App Servers

Load data file 0.5% 2 3 5

Load data Retrieve - Smart view 2.3% 12 17 23

JNL Entry/Posting and un posting 2.3% 12 17 23

WDEF - Enter data/save and Calculate 46.5% 233 352 465

Data Grid - Enter/Submit Data, Calculate 23.3% 116 174 233

Process Management - Force Calculate 2.3% 12 17 23

Process Management - Promote 3.5% 17 26 35

Run Journal report 2.3% 12 17 23

Run ICP report 0.7% 3 5 7

Run Retrieves - Smart View 11.6% 58 87 116

Hyperion Reports 4.7% 23 35 47

Total Users 100% 500 750 1,000


Figure 2 below shows the average logon times from each of the three non-consolidation tests (1, 2

and 3 HFM Application Servers). The Logon requests are handled primarily by the Workspace and

Foundation Services. These processes were not a bottleneck in the tests so response times were

fast and stable throughout all three tests.

Figure 2

Workspace Logon Response Times


In Figure 3 we see that after an initial, brief warm-up period open application times gradually

increased with load. Here we can see the improvement in response times and capacity when

additional HFM Application servers are added. Each server could was able to handle 350 users

while keeping the average response time at or below 7 seconds.

Figure 3

Open Application Response Times


Figure 4 shows the response times for opening Web Data Entry Forms. Again we clearly see that

the addition of HFM Application Servers increases the load the system can handle while

maintaining sub-second response times. Figures 5 and 6 are similar charts for displaying ICP

Reports and Journal Reports. The initially higher response times for displaying Journal reports

with 3 HFM Application Servers are due to loading of new data that had not previously been

brought into memory. Once the data were loaded the response times were much faster.

Figure 4

Open Web Form Response Times


Figure 5

Display ICP Reports Response Times

Figure 6

Display Journal Reports Response Times


A variety of different POV selections were made by the different users. Response times for setting

the POV based on the Year dimension is shown in Figure 7.

Figure 7

Set Year POV Response Times

Journals transactions such as opening, processing, closing, submitting, approving and deleting

followed the same trends in response times as the majority of transactions in these tests. Figure 8

shows the response times for posting Journals with 1, 2 and 3 Application Servers.

Figure 8

Journal Posting Response Times


RESOURCE USAGE VS. LOAD

CPU The busiest boxes were those running the HFM Application Servers. In the later stages of the tests

those servers were 50-70% busy with the HFM Application Servers using 5-6 of 8 CPU cores. The

CPU load was similar on the 3 Application Servers, but as expected due to the variable nature of

HFM requests it was not perfectly even. The HFM Web Server host averaged about 50-70% busy

(2-3 of 4 CPU cores) with the larger user loads. The Oracle RDBMS server occasionally spiked near

20-25% busy (2 of 8 CPU cores), coincident with increases in user load, but was otherwise about

10% busy. These are illustrated in Figures 9 and 10 below.

Figure 9

HFM Application Server CPU Usage


Figure 10

HFM Web. Workspace and DB Server CPU Usage


Memory HFM Application Server memory usage, both physical and virtual memory, is shown in Figure 11

for each of the 3 HFM HsvDataSource processes. Memory growth was minimal and evenly

distributed between the servers as load increased. A sudden jump in memory usage was observed

at 23:40 for one of the HFM Application Servers. This indicates that there was higher than average

concurrency at that point in time (due to random think times) or new data was accessed by the

server.

Figure 11

HFM Application Server Memory Usage


Figure 12 shows the physical and virtual memory usage for the HFM Web, Workspace (Foundation

Services) and DB Server. The HFM web server memory grew slightly as load increased but

physical memory usage remained well below 1 GB. All other memory trends were generally flat.

Figure 12

HFM Web. Workspace and DB Server CPU Usage


CONSOLIDATION TESTS A key function of Hyperion Financial Management is consolidations. We chose to run up to 15

concurrent consolidations on each of the 3 configurations (1, 2 and 3 HFM Application Servers).

The consolidations were run on 15 different years that each contained a copy of the same data and

rules. Therefore all 15 consolidations performed the same amount of work and had no overlapping

data. The consolidations were run as “All with Data”, an intensive consolidation.

RESPONSE TIMES The chart in Figure 13 shows the average execution times for each consolidation test. The three

different lines correspond to the three configurations. This shows that adding a second and third

HFM Application Server to the configuration noticeably improved response times. Adding a second

HFM Application Server increased capacity by 100% compared to the single HFM Application

Server configuration, while adding a third HFM Application Server added only 50% more capacity

compared to the two HFM Application Server configuration. As a result the reduction in response

times was greater going from 1 to 2 HFM Application Servers than it was going from 2 to 3 HFM

Application Servers. A single consolidation was run only with the 1 HFM Application Server

configuration since additional HFM Application Servers would have no effect on a single

consolidation. But the response time of a single consolidation provides a baseline for the other

tests, showing the minimum response time for this consolidation.

Figure 13

Consolidation Response Times


RESOURCE USAGE

CPU CPU usage during consolidations is almost entirely on the HFM Application Servers. Figure 14

shows the server CPU usage for all servers in the 15 consolidation, 3 HFM Application Server test.

Since all 15 consolidations performed the same amount of work, the load was very evenly

distributed between the 3 HFM Application Servers. Aside from a spike at the beginning when the

consolidations were submitted, the HFM web server used virtually no CPU. The Shared Services

server was very lightly loaded and the DB server was about 10-15% busy at the peak.

Figure 14

Server CPU Usage – 15 Consolidations – Three Application Servers


Memory Memory usage during the 15 consolidation, 3 Application Server test is shown in Figures 15 and 16.

Figure 15 focuses on the HFM Application Servers and shows very similar memory usage for all 3

HFM Application Servers. The software clearly benefited from running as a 64-bit process by

utilizing more than 2 GB of virtual memory per process to handle the large amount of data involved

with 15 consolidations. Memory usage for the HFM Web Server, OHS and the Shared Services was

much lighter and is depicted in Figure 16.

Figure 15

HFM Application Server Memory Usage – 15 Consolidations – Three Application Server


Figure 16

HFM Web, OHS, Shared Services Memory – 15 Consolidations – Three Application Servers

CONCLUSION The data presented here show the scalability and performance of Oracle’s Hyperion Financial

Management software. Using a very large customer application and a scenario of ramping up

mixed activity user load at regular intervals, a system with a single HFM Web Server and 3 HFM

Application Servers was able to support 1000 non-consolidation users. On average each HFM

Application Server handled up to 300-350 non-consolidation users with little or no increase in

response times. The maximum user load was limited by available CPU on the HFM Application

Server hosts. Adding more Application Servers on additional machines would further increase the

capacity of the system. As in these tests, systems with large concurrent user loads and/or data

volumes will benefit from running HFM as a 64-bit application on a 64-bit operating system.

Memory could be a limiting factor on 32-bit systems.

Consolidation tests also showed excellent scalability as HFM Application Servers were added to the

system. Response times for concurrent consolidations improved significantly with more HFM

Application Servers. Very little overhead was noticed for multiple HFM Application Servers as 3


HFM Application Servers handled 3 identical consolidations nearly as fast as a single consolidation

on a single HFM Application Server.

Many of the factors affecting capacity and performance are heavily dependent on the actual usage

of an environment and the design of the HFM applications. The application used in these tests was

above average in size and complexity. Smaller applications will require fewer resources and will

have less contention when consolidations are run. The only way to adequately predict

performance and capacity of a specific system is to perform load tests on that environment with

the applications and use cases that actual users will follow.

For information on tuning Hyperion Financial Management systems please see Hyperion Financial

Management (HFM) Performance Tuning Guide, Fusion Edition.

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1083460.1#WP_BODY

https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1083460.1#WP_BODY

Hyperion Financial Management 11.1.2.1 Performance Report

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200

oracle.com

Copyright © 2011, Oracle. All rights reserved.

This document is provided for information purposes only and the

contents hereof are subject to change without notice.

This document is not warranted to be error-free, nor subject to any

other warranties or conditions, whether expressed orally or implied

in law, including implied warranties and conditions of merchantability

or fitness for a particular purpose. We specifically disclaim any

liability with respect to this document and no contractual obligations

are formed either directly or indirectly by this document. This document

may not be reproduced or transmitted in any form or by any means,

electronic or mechanical, for any purpose, without our prior written permission.

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle

Corporation and/or its affiliates. Other names may be trademarks

of their respective owners.

Documents

HFM Performance Report