HFM Performance Report

Oracle

Oracle

_{Hyperion Financial}

_{Hyperion Financial}

Management 11.1.2.1

Management 11.1.2.1

Performance Report 

Performance Report 

Oracle

Oracle

_{Hyperion Financial Management 11.1.2.1}

_{Hyperion Financial Management 11.1.2.1}

Performance Report 

Performance Report 

T

T

ABLE OF

ABLE OF

C

C

ONTENTS

ONTENTS

Executive Overview ...Overview ... 4... 4 Introduction

Introduction ... ... 44 Test

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

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

Tuning ... ... 66 HFM

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

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

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

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

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

Results ... ... 88 Non-Consolidation

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

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

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

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

Response Times ...Times ... 1... 188 Resource

Resource Usage ...Usage ... 1... 199 Conclusion

Oracle

_{Hyperion Financial Management 11.1.2 Performance Report} 

E

XECUTIVE

O

VERVIEW

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.

I

NTRODUCTION

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.

Hyperion Financial Management 11.1.2.1 Performance Report Page 5

T

EST

C

ONFIGURATION

H

S

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 8 cores x 2.33 GHz, 12 GB RAM HFM App Server 3 8 cores x 2.33 GHz, 12 GB RAM Workspace, HSS 4 cores x 2.41 GHz, 3.8 GB RAM HFM Web Server  4 cores x 2.41 GHz, 3.8 GB RAM ` LoadRunner  Controller/Agent Database Server  8 cores x 2.40 GHz, 7.8 GB RAM LDAP Server  2 cores x 2.79 GHz, 4 GB RAM

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.

T

The following tuning adjustments were made to the system prior to running the tests described in this paper.

HFM  APPLICATION S ERVERS 

HFM UI Configuration settings:

Number of Pooled DB Connections = 200

Registry Settings

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"

T

S

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.

Hyperion Financial Management 11.1.2.1 Performance Report Page 7 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

LOADRUNNERS CRIPTS 

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

R

ESULTS

N

-C

T

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 T IME 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

Hyperion Financial Management 11.1.2.1 Performance Report Page 9 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

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

Hyperion Financial Management 11.1.2.1 Performance Report Page 11 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

Figure 5

Display ICP Reports Response Times

Figure 6

Hyperion Financial Management 11.1.2.1 Performance Report Page 13 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

RESOURCE U SAGE 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

Hyperion Financial Management 11.1.2.1 Performance Report Page 15

Figure 10

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

Hyperion Financial Management 11.1.2.1 Performance Report Page 17 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

C

T

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 T IMES 

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

Hyperion Financial Management 11.1.2.1 Performance Report Page 19

RESOURCE U SAGE 

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 cons olidation, 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

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

Hyperion Financial Management 11.1.2.1 Performance Report Page 21

Figure 16

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

C

ONCLUSION

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.

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 rig hts 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 o r 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 affil iates. Other names may be trademarks