interactive reporting capacity planning report - ir 11.1.1 windows

Hyperion Interactive Reporting 11.1.1 Capacity Planning Report for Windows An Oracle White Paper May 2009

Hyperion Interactive Reporting 11.1.1 Capacity Planning Report for Windows

Executive Overview.................................................................................................................... 3 Introduction ................................................................................................................................. 3 Scope............................................................................................................................................. 4 Test Configuration ...................................................................................................................... 4

Hardware Setup....................................................................................................................... 4 Hyperion Architecture Layout Details ............................................................................ 5

Tuning ...................................................................................................................................... 5 Test Scenario ........................................................................................................................... 6

Results ........................................................................................................................................... 8 Response Time vs. Load........................................................................................................ 8 Resource vs. Load................................................................................................................. 11

CPU.................................................................................................................................... 11 Memory.............................................................................................................................. 14 Network............................................................................................................................. 16 Disk .................................................................................................................................... 17

Implications for Capacity Planning ........................................................................................ 17 Capacity Planning Tables..................................................................................................... 17

Using the Interactive and Production Reporting Capacity Planning Tables........... 19 Adjusting for Different Test Scenarios......................................................................... 19

When to Cluster/Replicate Services .................................................................................. 20 Tuning Interactive Reporting Systems................................................................................... 20

Heap Sizes.............................................................................................................................. 20 Workspace Web Heap Settings ...................................................................................... 21 Workspace Service Heap Settings.................................................................................. 21

Data Access Service Parameters ......................................................................................... 21 BIService Parameters ........................................................................................................... 21 Workspace Service Parameters ........................................................................................... 22 Application Server Threads................................................................................................. 22

Resolving Resource Issues ....................................................................................................... 22 Processing Issues .................................................................................................................. 22 Memory Issues ...................................................................................................................... 23 Disk Access Issues................................................................................................................ 24

Conclusion.................................................................................................................................. 24 Appendix A Test Scenario Details ...................................................................................... 25

Contents of Workspace Repository ................................................................................... 25 Query Activity ....................................................................................................................... 27 Profile of Simulated Users................................................................................................... 27 Activity Measurements......................................................................................................... 28

Mixed Workload Test ...................................................................................................... 28

Hyperion Interactive Reporting 11.1.1 Capacity Planning Report for Windows Page 2

Hyperion Interactive Reporting 11.1.1 Capacity Planning Report for Windows

EXECUTIVE OVERVIEW This document summarizes performance testing for Hyperion Interactive Reporting, a component of Oracle Enterprise Performance Management (EPM) System. These tests used EPM version 11.1.1 running Microsoft Windows 2003 on HP ProLiant BladeSystem servers provided by HP. Tests demonstrated the softwares ability to support more than 1,000 users on a basic configuration.

The results presented here represent one of several sources of information that are typically used to plan

hardware capacity for a Hyperion Interactive Reporting implementation. This white paper is intended for

preliminary capacity planning use only and is not to be interpreted as a benchmark or general statement of the

performance and scalability characteristics of Hyperion Interactive Reporting software.

INTRODUCTION Performance testing and capacity planning for enterprise applications such as Oracles Hyperion Intelligence Reporting tool is a complex task. To demonstrate the ability of Hyperion Interactive Reporting to support large user populations while delivering quick response times on Windows servers, Oracle partnered with HP to conduct large-scale performance tests. The results of these tests prove the scalability of Hyperion Interactive Reporting on Windows servers and provide data that can be used for preliminary sizing estimates.

Hyperion Interactive Reporting connects business users to data and gives them a complete set of tools to support business decisions including ad hoc client/server querying, reporting, and analysis in one application. Hyperion Interactive Reporting provides the following capabilities:

Data extraction and analysis

Reporting and distribution

Platform development

Hyperion Interactive Reporting is an all-in-one query, data analysis, and reporting tool. The interface is highly intuitive and provides an easy-to-navigate environment for data exploration and decision-making. With a consistent design paradigm for query, pivot, charting, and reporting, users at any level move fluidly through cascading dashboards to find answers quickly. Trends and anomalies are automatically highlighted, and robust formatting tools enable users to easily build free-form, presentation-quality reports for broad-scale publishing across their organizations.


SCOPE This paper focuses on the performance testing of Hyperion Interactive Reporting only, and tuning of database and Web servers is out of its scope. This document covers Hyperion Interactive Reporting installations on Windows Server 2003 machines only.

TEST CONFIGURATION

Hardware Setup HP provided HP ProLiant BladeSystem Servers and HP Enterprise Virtual Array (EVA) Storage at one of its testing labs. The configuration used for Hyperion Interactive Reporting comprised six servers and a storage array as described below.

Hostname Model Processors Memory Function HPBLADE4 HP ProLiant BL460c 2 proc, quad core Xeon 2.66 GHz 16 GB Apache Server HPBLADE1 HP ProLiant BL460c 2 proc, quad core Xeon 3.166 GHz 32 GB Web Tier HPBLADE5 HP ProLiant BL460c 2 proc, quad core Xeon 2.66 GHz 24 GB Service Tier

HPBLADE11 HP ProLiant BL460c 2 proc, quad core Xeon 2.66 GHz 16 GB Shared Services, SunONE LDAP

HPBLADE12 HP ProLiant BL460c 2 proc, quad core Xeon 2.66 GHz 24 GB Essbase

HPBLADE13 HP ProLiant BL460c 2 proc, quad core Xeon 3.166 GHz 32 GB Oracle

HP SAN_1 EVA4100 (28 disks, 136 GB each, RAID01)

HP SAN_2 HP StorageWorks SB40c (six disks, RAID01)


Hyperion Architecture Layout Details

Apache was installed on one server and configured to load-balance among five instances of the Workspace servlets on another server. The Workspace Service and five instances of the Hyperion Interactive Reporting services were configured on a third server. A fourth server hosted the Hyperion Shared Services, Open LDAP, and the SunONE Directory Server. The Oracle database ran on its own server, as did Essbase. The Oracle and Essbase servers ran as 64-bit applications; all other processes ran as 32-bit applications. An HP EVA4100 (28 disks, 136 GB each, RAID01) was used for the SAN in the services tier. An HP StorageWorks SB40c (six disks, RAID01) was used as SAN storage for Oracle database storage.

Tuning This section provides information for tuning the Hyperion Interactive Reporting system for best performance with the test scenario used here.

Apache o MaxKeepAliveRequests 0 o

ThreadsPerChild 2048 ListenBacklog 2000

o LogLevel crit

WebLogic/ Workspace Servlets

o Java heap settings: -Xms1200M -Xmx1200M o Root log level: ERROR


Workspace Services

o Usage Tracking, Harvester services: HOLD o Number of connections for Services: 3,000 o Java heap settings: -Xms1200M -Xmx1200M o Root log level: ERROR

SunONE LDAP

o Database cache size: 100 MB o Entry caches: 100 MB

Oracle RDBMS

Parameter Name Location Value shared_pool_size spfile/init.ora 300000000db_cache_size spfile/init.ora 700000000large_pool_size spfile/init.ora 8388608open_cursors spfile/init.ora 1000processes spfile/init.ora 1000sessions spfile/init.ora 1000sort_area_size spfile/init.ora 1000000sort_area_retained_size spfile/init.ora 65536timed_statistics spfile/init.ora FALSEdb_file_multiblock_read_count spfile/init.ora 4optimizer_index_cost_adj spfile/init.ora 20optimizer_index_caching spfile/init.ora 20

Test Scenario Client loads for Hyperion Interactive Reporting testing were simulated using LoadRunner 8, an HP load-testing tool. LoadRunner enables users to record browser actions in 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. The ability to record network traffic is a requirement for testing Hyperion Interactive Reporting. 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.

Three test scripts were created with LoadRunner: one simulating Foundation users who access nonquery content, another for Hyperion Interactive Reporting Web Client users, and the third for Hyperion Interactive Reporting thin-client users. Simulated user actions include opening documents and processing queries in Hyperion Intelligence Reporting documents (BQY files). Random think times were included between actions in all scripts. Three types of think time intervals were used in the tests. Shorter think times, 215 seconds, were used everywhere except for actions with BQY files. When working with BQY files, medium think times, 1530 seconds, were used between changing sections, and longer think times, 120180 seconds, were used after processing queries. Longer think times simulated users taking time to view the results of queries and examine charts and reports. File names were replaced with random variables that selected from a list of file names representing copies of the same file.


This was done to allow random file selection and guarantee the validity of subsequent actions with that file, no matter which file was randomly chosen. User names used to log into the EPM System were chosen randomly from 10,000 total registered users, ensuring that many different users logged in during the course of testing.

Find Additional details of the test scenario in Appendix A.


RESULTS

Response Time vs. Load Response times for logging in to the EPM system and browsing repository folders was quite fast throughout the test, showing virtually no degradation with increased load, because a large portion of this work was performed on the Web tier, which was not as heavily used as the services tier.


Web Client response times also were fast throughout the test, because most of the Web Client processing occurs on the clients and not on the servers.

In contrast, thin-client response times increased with load because most of this work is done on the services tier. Because of the nature of thin-client applications, placing the load on the servers instead of the clients, the services tier became quite busy as load increased. The following charts show the effects on thin-client response times for various transactions.


The calculations performed in the creation of Report and Chart sections are particularly intensive. Response times for charts are directly proportional to the amount of data included in the charts. Those with more data, such as Chart2, can be affected significantly as load increases.

Resource vs. Load

CPU

By far, the busiest box was the services server, hosting the Workspace Service, the BIService, and the Data Access Service. That server was 80% busy in the later stages of the test. The other servers were less than 20% busy through most of the test, illustrated in the chart below.


On the Web tier, Apache and Workspace both peaked at about 150% utilization, or 1.5 CPU cores. The Workspace CPU time was evenly split among five instances, each running in its own JVM.


Looking closely at the services host, we see that the majority of the CPU time was used by the BIService. There were five instances of the BIService, and the total CPU time shown here was split equally among them. The Workspace Service was the second largest consumer of CPU time, followed by the Data Access Services (DAS). The DAS is responsible for sending SQL queries to the data source when users process queries in their documents. As a result, the CPU time required for the DAS is related to the percentage of users who process queries. In our case, 10% of the user population processed queries; the remaining 90% only viewed the data saved with the report. For implementations expecting a larger percentage of users processing queries, the DAS CPU requirements will be proportionately larger.


Memory

Memory use on the Web tier was relatively flat for the duration of the test. Workspace memory use was driven by the Java heap settings, which were set to 1200 MB for the minimum and maximum.


On the Services tier, memory for the Workspace Agent and the DAS services was stable. Memory usage for the BIService, which handles most of the processing for thin client requests, increased linearly with user load. The chart below shows the total memory use for all instances of each process. This test included five BIService processes and five DAS processes.


Network

The Workspace and Services servers were configured with two network cards each, with the first card handling the smaller incoming requests and the second card handling the larger response data. The Apache server was configured with only one card; as a result, it was the busiest network card in the system. The Oracle and Essbase network cards were not busy, as the following chart illustrates.


Disk

Examining disk queues is the best way to measure disk use. Besides a few short spikes, disk queues were almost nonexistent, indicating that disk usage was not a bottleneck.

IMPLICATIONS FOR CAPACITY PLANNING The configuration handled more than 1,400 users without fatal errors. Depending on the volumes of data used in reports, the response times for this number of users may not be acceptable. This system handled 600 users with virtually no increase in response time when compared to single-user performance. Ignoring the Chart2 transactions, response times remained shorter than 20 seconds through approximately 1,000 users, suggesting that this system could be acceptable for environments with occasional peak use of up to 1,000 users. Because delays were almost entirely with thin-client transactions, moving more users to the Web Client would further increase the capacity of these servers.

Capacity Planning Tables The Windows capacity planning tables presented here were created to provide initial sizing estimates. They are based on the resource use presented in the previous section, for the test described in Appendix A. These tables provide estimates for individual services and not for server hosts. After the services distribution across hosts is determined, the capacity requirements can be summed for each host.

The following must be considered when using these tables:


o The specific use of an Hyperion Interactive Reporting system has a significant effect on the capacity of the system. Appendix A: Test Scenario Details provides details about the testing scenarios and documents used to produce the capacity estimates presented here. That scenario should be used as a reference to compare with anticipated Hyperion Interactive Reporting usage in other implementations so that appropriate adjustments can be made.

o Memory requirements are highly dependent on the amount of data contained in reports. Reports larger than those described in Appendix A will require more memory than the capacity planning tables recommend.

o The data provided in the tables below are based on average use for each load level. Peak periods of use may require additional resources.

o Except as noted in the tables, CPU estimates are based used Quad-Core Intel Xeon processors operating with a 2.66 GHz clock. If older processors with slower speeds and/or single cores are used, additional CPUs may be needed.

o Each instance of a process has some initial memory footprint to load the software into memory. Therefore, the total memory for multiple instances may be higher than for a single instance servicing the same load.

Table 1 Processor Capacity Planning Table*

1100 Users 100500 Users 500750 Users 7501000 Users 10001500 Users

CPU Cores CPU Cores CPU Cores CPU Cores CPU Cores Workspace Service 0.10.3 0.20.9 0.71.4 1.21.8 1.52.5

BIService 0.30.7 0.52.3 1.83.5 3.05.0 4.07.0

DAS 0.10.2 0.20.4 0.30.6 0.50.8 0.71.0 Web Server (Apache) 0.10.2 0.10.7 0.51.0 0.81.4 1.02.0

Workspace Web 0.10.2** 0.10.7** 0.51.0** 0.81.4** 1.02.0** Shared Services

Using the Interactive and Production Reporting Capacity Planning Tables

Based on the tables above, to support 500 active users, the configuration should include approximately eight CPU cores as follows:

0.9 for the Workspace Service with GSM 2.3 for the BIService 0.4 for the DAS 0.7 for the Workspace Web application 0.7 for the Apache Web server 0.1 for the Shared Services 0.1 for the LDAP Server

The total would be 5.2 cores. To be conservative, to allow for periods of higher peak use, and to account for cores/processors usually being installed as pairs, the number should be rounded up to eight cores. The recommended distribution of the services would be across two machines as a starting point (Web server and servlets on a two-core machine, Workspace Service, BIService, DAS, Shared Services, and LDAP Server on a six-core machine). If there is no requirement for a firewall between the Web and services tier, one eight-core server also would work well. A general, conservative guideline is that, of an organizations user population, 10% would be active on the system at any time (10% of the total users eligible to log on would be logged in). Therefore, the 500 active users here on these 10 cores represent a total user population of 5,000 users. If usage increases, the BI and DAS services can be moved to an additional machine.

Adjusting for Different Test Scenarios

The performance achieved in any system will be highly dependent on the specific usage scenario. The percentage of users processing queries vs. running reports, the size of the result sets, and the complexity of the reports significantly affect resource usage and response times. Perhaps the most crucial factor is the number of users running each type of client: the thin client or Web Client. The nature of thin-client applications places much more load on the servers than does a fat client. In the test reported here, 50% used the thin-client interface. For systems with a different number of thin client users, the resource usage will change proportionately, primarily on the services host and specifically for the BIService. Likewise, the Data Access Service resource usage will change in proportion to the number of users who process queries through both the thin client and Web Client. The following example illustrates how to adjust resource requirements for different scenarios.

Consider the case of Intelligence Web Client users with no thin-client users. Say that 50% of Web Client users process queries instead of 10%. The changes to the scenario would be:

1. Intelligence Web Client use increases from 40% to 90% (still have 10% Foundation users). 2. Thin-client use drops from 50% to 0%. 3. Query processing increases from 10% to 50% .

To accommodate each change, these adjustments must be made to the estimates:

1. Do not increase resources for additional Intelligence Web Client users. Moving users from the thin client to the Web Client transfers work to client machines, away from the servers.

2. Decrease BIService requirements to 0, because there will be no thin-client users. 3. Increase DAS resources by a factor of five.


Using the example of 500 active users from the previous section, the CPU requirements would now be:

0.9 for the Workspace Service with GSM 0.0 for the BIService 2.0 for the DAS 0.7 for the Workspace Web application 0.7 for the Apache Web server 0.1 for the Shared Services 0.1 for the LDAP Server

This adds up to 4.5 cores. Rounding up for higher peak periods and installing cores in pairs would increase this number to six cores. In this new case, the DAS becomes the busiest service instead of the BIService. The recommended distribution of these six cores is a similar two-box configuration, as in the previous example (Apache and Workspace Web on a two-core machine, and Workspace Service, BIService, DAS, and Shared Services on a four-core machine). Again, using the general guideline that 10% of an organizations user population would be active on the system at any time, this hardware could support a user population of up to 5,000 users running this scenario.

These two scenarios illustrate the need to adequately estimate the anticipated usage of a system before planning capacity. The same total number of users can require different resources for different usage scenarios; sometimes drastically different resources are required.

When to Cluster/Replicate Services The primary factors driving replication of services are memory usage (if the service needs more memory than a 32-bit process can access), and CPU (if not enough processors are on one server). If the Workspace Web application, BIService, or DAS needs more than 2 GB of virtual memory, and physical memory and CPU cycles are available, those components may be replicated on a single host. If the host does not have sufficient physical resources, they can be replicated on additional servers. Portions of the Workspace Service also may be replicated on additional servers if more resources are required. See installation and administration documentation for additional information on replicating services.

The number of CPUs and the memory required will vary not only for user load, but also based on the amount of data accessed. For thin-client users the data includes the number of calculations performed in each BQY file and the complexity of charts and pivot tables. Therefore, it is impossible to offer a guideline for the number of users that can be supported per instance of the services. To determine optimal clustering and replication for an implementation, testing must be performed with the actual reports and user scenarios expected.

TUNING HYPERION INTERACTIVE REPORTING SYSTEMS

Heap Sizes Adjusting the Java heap sizes for the Workspace Web servlets and Workspace Service can improve performance and increase the load that these applications can handle. java.lang.OutOfMemory errors in the logs indicate that insufficient heap has been allocated.

Because the overall size is effectively limited to 2 GB for 32-bit processes, the recommended maximum heap should not exceed 1.3 GB, to allow enough space for the JVM itself and for threads to allocate extra space for their stacks.


If an message indicating that there is insufficient memory to create a new thread accompanies an out-of memory error, the heap is too large, which means that there is not enough process memory left for nonheap allocations, such as those needed to create threads. When thread creation fails, the maximum heap size must be set smaller.

Workspace Web Heap Settings

The Workspace servlets maintain session information for each user. Consequently, they perform best when provided with plenty of Java heap. Maximum heap sizes of 1.0 GB may be necessary for several hundred concurrent active users. Change the heap size for the servlets by adding Java arguments to the application server. If thousands of concurrent users are required, and a 32-bit application server is selected, more server clones should be created to provide more total memory for the Workspace servlets. The application server vendor also may suggest tuning other parameters, such as those associated with garbage collection, for better performance.

The Workspace Web application heap should be adjusted within the application server console or in the application server startup file. Refer to the application server documentation to determine the correct adjustment of these settings.

Workspace Service Heap Settings

The EPM System Workspace Service probably also will need a heap size adjustment. The maximum heap needed depends on the peak number of users logged into the system and the number of objects published to the EPM repository. A good starting value is 768 MB for up to approximately 600 active users. A larger maximum heap may be needed for larger loads. The minimum heap size also should be increased. Ideally, to avoid performance penalties for increasing the heap, make the minimum heap size equal the maximum heap size.

The Workspace Agent heap size can be adjusted by changing the Xms and Xmx parameters for the Workspace Service using the Configuration Management Console. The Xms setting specifies the minimum size; the Xmx setting specifies the maximum size.

Data Access Service Parameters Changing the value of the Relational Partial Result Cell Count parameter can improve BQY query performance. This parameter, set in the Data Access Service parameters in the Configuration Management Console, specifies how many bytes of data that the DAS should retrieve from the database in one fetch. A value of 500,000 works well for queries returning 200,000 to 20,000,000 bytes of data. Similarly, changing the mdd Partial Result Cell Count parameter can improve BQY query performance for multidimensional queries. Increasing the value for large queries can result in fewer data fetches and less overhead but causes increased memory use by the DAS.

BIService Parameters If BIService memory use is high, adjusting the value of the Document Unload Timeout parameter, found in the Intelligence Service properties in the CMC, may help. This parameter indicates how long a thin-client document will remain inactive in the cache until it is removed from the cache. The value is in seconds; the default is 900 seconds (15 minutes). Decreasing this value will remove documents from the cache sooner, thereby freeing memory sooner. It could also mean that documents will need to be retrieved from the repository more often, so carefully consider this tradeoff before choosing a value for each installation.


If keyboard navigation is not required, BIService memory usage can be reduced by adding

DISABLE_KEYBOARD_NAV_IN_NON_508_MODE=true to the Dynamic Service Properties of the Intelligence Service through the Configuration Management Console.

Workspace Service Parameters The Workspace Service is a set of service agents that run as a single process (the Workspace Agent process). The maximum connections to each service agent is 100 by default. Under load, this value may not be sufficient. In general, use these guidelines to set the proper number of connections:

Service Broker and Repository Manager: number of active users + number of jobs that can run at any given time + 50

Job Service: number of concurrent jobs * 1.1

Event Service: 100 or the number of jobs that can run at any given time, whichever is greater.

The number of connections for each service agent can be changed using the Service Configurator tool.

The Workspace Service uses a connection pool for communications with the repository database. In the testing described here, the default pool size of 50 concurrent connections was used. The value may need to be adjusted for different EPM System implementations. To change the value to 100, for example, add Dmax_db_pool_size=100 to the list of JAVA_OPTS for the Workspace Service Properties in the Configuration Management Console (CMC). Note that increasing this value increases the amount of memory that the Workspace Service uses, regardless of whether the connections in the pool are used. Therefore, keep this value as low as possible. An EPM system with a single Workspace Service using a max_db_pool_size of 50 supported more than 1,400 active users without running out of database connections.

Application Server Threads For a mixed workload such as that described in Appendix A of this document, the number of application server threads required will be low, roughly 20% of the number of active users. However, if many users are running queries that take more than a few seconds to complete, the number of threads must be increased, because the application server thread issuing a query will remain in use until all of the results of the query are returned. Manual tuning is unnecessary when using WebLogic 9 as application server, because it can adjust the number of threads automatically based on current load requirements. Other application servers may need manual tuning.

RESOLVING RESOURCE ISSUES

Processing Issues Possible ways to resolve processing issues with the Hyperion EPM System:

Reduce the number of concurrent BQY and/or SQR jobs so that fewer jobs run at one time. Replicate and distribute the different components of the architecture. Increase the number and/or speed of processors on your machines.


If the SQR job response times are slow at peak times because of a CPU bottleneck, try setting the maximum number of concurrent jobs to a smaller number. To limit the number of concurrent jobs to five, for example, add the string -Djob_limit=5, to the JAVA_OPTS argument for the Workspace Service in the Configuration Management Console to allow more resources for each job and result in fewer CPU context switches. Some jobs may be queued waiting to run, but the time saved with fewer context switches should more than make up for the queue time. Tuning of the maximum jobs parameter must be refined through trial-and-error testing in each environment. If necessary, Job Services may be installed on additional machines to increase the capacity for concurrent jobs.

The same concept of limiting concurrent jobs applies to BQY jobs. By default, each IRJob service runs, at most, five concurrent jobs. To limit the number of concurrent jobs to three, for example, set that value for the Maximum Concurrent Job Requests parameter for the Hyperion Interactive Reporting Job Service in the Configuration Management Console.

If the EPM services run on the same machine as the database, install them on different machines so that the EPM services do not compete with the database for CPU cycles. If the response times are still slow, and the EPM services are running on the same machine as the Web server and servlets, move the Web and application servers to their own machine.

To improve thin-client response times when a CPU bottleneck exists, consider replicating the Intelligence Server (BIService) on another machine. If many queries are processed, also replicating the DAS may help.

To improve Intelligence Web Client response times, replicating the DAS service should help when many queries run concurrently. An additional set of servlets, with users load-balanced by the Web server, also may help. It is important to first identify whether the servlets or services are causing the bottleneck of the system so that the proper component can be replicated.

Memory Issues If the EPM System is memory-bound, the OS statistics will show memory use for EPM processes approaching the 32-bit OS limit of 2 GB. If the machine lacks sufficient physical memory, there will be a consistently high paging rate accompanied by a small amount of free memory. If this occurs, consider adding more RAM if possible. Also be sure there is sufficient page file space.

It is possible that the server has enough memory, but specific processes may not be allocated as much as they need. For example, Java processes are limited by the maximum heap, and 32-bit processes, compiled without flags to use extended memory, can use only 2 GB of memory. To check the amounts of memory used by the Common Services and Workspace servlets, examine memory usage information provided in the services and servlets logs. Most application servers provide administration consoles that also may be used to monitor servlets and Web application memory usage. The BIService also writes its memory usage information into its own log file. Periodically checking these files can help diagnose possible memory problems.

If memory causes a bottleneck for the BIService process, consider replicating that service. If the machine has plenty of memory available, the BIService can be replicated on the same machine, or on another machine. Likewise, if Workspace memory is an issue, multiple Workspace deployments can be used, on either one machine or multiple machines.


Disk Access Issues If the Hyperion EPM System is experiencing disk access issues, first consider using RAID 0 (pure striping) or RAID 0+1 striping. RAID 0 should provide the best performance, but it does not provide data redundancy. For performance and data redundancy, Oracle recommends using RAID 0+1 (or RAID10, mirrored striping). If RAID 0+1 is too expensive to implement (because of the number of required disks), another solution that provides data redundancy is RAID 5 (striping with parity). If your enterprise chooses to implement a RAID 5 solution, select a hardware RAID 5 solution (with buffering), because it should perform much better than the software RAID 5 solution. Be sure to stripe data across at least four disks. Other, newer disk technologies may also work well. Consult your system administrator for the best disk solution for your environment.

In addition, consider these recommendations for reducing disk bottlenecks:

Isolate the EPM System Servers, Web server, and the databases from one another, or at least have them access disks on different controllers.

Compress BQY files so that less data is transferred to and from disks. Avoid excessive writing to log files, which can quickly create a disk bottleneck.

CONCLUSION The data presented here show the scalability and performance of Hyperion Interactive Reporting software. Using a scenario of ramping up user load at regular intervals, the configuration provided by HP was able to support more than 1,400 users, a mix of Web Client and thin-client users. Web Client response times were very good throughout the test. Thin-client response times were acceptable through approximately 1,000 users. The most heavily used server was that used for the services. The other servers were minimally loaded throughout the test.

Note that this configuration could support more users if the thin-client users converted to the Web Client. Doing so transfers much of the processing activity from the servers to the individual client machines, enabling the servers to handle more of the work that can be performed only on the server side. For a similar test scenario with only Web Client users, the configuration used likely would support more than 2,000 active users, depending on report content and the amount of query processing. Assuming that 10% of a user population is actively using the system at a given time, this configuration could support a total user population of 20,000 or more.

And, finally, because many factors affecting capacity and performance are dependent on the actual usage of a specific environment, the only way to adequately predict capacity is to perform load tests on that environment with the documents and use cases that actual users will follow.


APPENDIX A: TEST SCENARIO DETAILS

Contents of the Workspace Repository The Intelligence Reporting system was populated with more than 12,000 nonquery documents and 300 BQY files, each with both Hyperion Interactive Reporting Web Client and thin-client versions. The BQY files were compressed and included one query, one result, one pivot, three charts, one report, and two dashboard sections. The results section included five computed columns.

Figure 1 shows a segment of the folder tree structure. Each SSubCat folder contained the same three BQY documents. All of these documents used the same OCE file published in the root folder.

Figure 1

Documents in SSubCat0 Folder


A sample of a BQY document is shown in Figure 2. The difference between each file was the number of rows in the results set. The results set contained 1,000, 10,000 or 100,000 rows. Each row contained approximately 200 bytes of data plus five computed fields.

Figure 2

Sample BQY Document


Query Activity The query used for tests:

Select CUST_NUM NAME ADDR1 ADDR2 CITY CUSTOMERS001K.STATE ZIP PHONE TOT SALES PROFITS REGIONS.STATE STATEABBR REGION TIMEZONE From CUSTOMERS_TABLE, REGIONS Where CUSTOMERS_TABLE.STATE = REGIONS.STATEABBR

Here CUSTOMERS_TABLE is a variable for one of these tables: CUSTOMERS001K with 1,000 rows of data CUSTOMERS010K with 10,000 rows of data CUSTOMERS100K with 100,000 rows of data Profile of Simulated Users The test results are heavily dependent on the profile of user activity. For data consistency and testing purposes, a set of user profiles was implemented during the course of testing. A brief description:

10% of active users executed the Foundation tests. 50% of active users opened Hyperion BQY documents through the thin client. 40% of active users opened Hyperion BQY documents through the Intelligence Web Client. 10% of users who opened a BQY document through the thin client processed a query within the

document.

10% of users who opened a BQY document through the Web Client processed a query within the document.

100% of users who opened a thin client document opened each section (such as Report, Chart, and Pivot) of the document.

25% of thin-client users did not properly close BQY documents after opening them. 10% of Hyperion Interactive Reporting users (both thin client and Web Client) published and deleted

BQY documents.


Activity Measurements

Mixed Workload Test

The following tables describe the detailed actions in each of the three LoadRunner scripts.

Foundation Script Scenario

Transaction Timer Comment 1000 Home Open login page 1010 Login Submit login information 1020 Explorer Open Explorer module 1040 0010 Category Go to Folder with 10 items 1040 0100 Category Go to Folder with 100 items 1040 0500 Category Go to Folder with 500 items 1040 1000 Category Go to Folder with 1000 items 1050 TheRealWorld Go to TheRealWorld folder 1060 Category Go to Category0 1070 Subcat Go to SubCatN, N in 0..9 1080 View 100K Html Open 100 KB nonquery file 1080 View 1B Html Open 1 B nonquery file 1090 SSubcat Go to SSubCatN, N in 0..9 1100 SSSubcat Go to SSSubCatN, N in 0..4 1110 Sqr Jobs Folder Go to SQR_Jobs Folder 1120 Sqr Subfolder Go to SQRN, N in 0..9 1130 Publish 100K Step1 (*) Click on Publish file 1140 Publish 100K Step2 (*) Publish (upload) file 1150 Publish 100K Step3 (*) Submit publishing 1160 Subscribe 100K Step1 (*) Subscribe to file that was just published 1170 Subscribe 100K Step2 (*) Submit subscribing 1175 Personalpage (*) Go to Personal Page 1176 View 100K Favorite (*) Open published and subscribed file 1180 Delete 100K (*) Delete file that was just published 1190 Import Sqr Step1 (*) Click on Publish Job 1200 Import Sqr Step2_{filename} (*) Specify file to be published 1210 Import Sqr Step3_{filename} (*) Specify Advanced Options, Access Control 1220 Import Sqr Step4_{filename} (*) Specify connectivity and required files 1220 Import Sqr Step4 1_{filename} (*) Specify connectivity and required files 1240 Import Sqr Step5_{filename} (*) Define output types 1250 Import Sqr Step6_{filename} (*) Click on Finish 1270 Del Sqr Step1_{filename} (*) Delete published SQR 1290 Search Step1 Click on Search 1300 Search Step2 W1 Submit search, single keyword 1300 Search Step2 W1 And W2 Submit AND search 1300 Search Step2 W1 Or W2 Submit OR search 1300 Search Step2 W2 Submit search, single keyword 1305 Closeall Close all documents 1310 Logout Click on Exit

(*) 10% of all Foundation users execute these actions {filename} represents a randomly selected SQR file with the 10,000- or 100,000-row query


Hyperion Interactive Reporting Thin-Client Script Scenario

Transaction timer Comment 2000_Home Open login page 2010_Login Submit login information 2020_Explore Open Explore module 2040_TheRealWorld Go to TheRealWorld 2050_Category Go to Category0 2060_SubCat Go to SubCatN, N in 0..9 2070_SSubCat Go to SSubCatN, N in 0..9 2080_OpenBQY_{filename} Open randomly selected BQY file 2090_QueryBQY_{filename} Open Query section 2100_Results_BQY_{filename} Open Results section 2110_Pivot_BQY_{filename} Open Pivot section 2120_Chart_BQY_{filename} Open Chart section 2130_Chart2_BQY_{filename} Open Chart2 section 2140_Charts3_BQY_{filename} Open Chart3 section 2150_Report_BQY_{filename} Open Report section 2160_EIS_BQY_{filename} Open EIS section 2170_Process_BQY_{filename} (*) Process BQY 2180_Close_BQY_{filename} Close BQY 2200_BQY_Jobs_Folder Open BQY jobs folder 2210_BQY_Subfolder Open BQY jobs subfolder 2220_PublishBQY_Step1(*) Click on Publish file 2230_PublishBQY_Step2(upload)_{filename}(*) Specify file to be published 2240_PublishBQY_Step3(next) _{filename} (*) Specify connectivity 2250_PublishBQY_Step4(finish) _{filename} (*) Click on Finish 2260_PublishBQY_Step5(refresh)_{filename}(*)

Refresh content

2270_Delete_BQY (*) Delete just published BQY file 2270_Logout Logout

(*) 10% of all thin-client users execute this action. {filename} represents a randomly selected BQY file with the 1,000-, 10,000-, or 100,000-row query.


Hyperion Interactive Reporting Web Client Script Scenario

Transaction Timer Comment 3000_Home Open login page 3010_Login Submit login information 3020_Explore Open Explore module 3040_TheRealWorld Go to TheRealWorld 3050_Category Go to Category0 3060_SubCat Go to SubCatN, N in 0..9 3070_SSubCat Go to SSubCatN, N in 0..9 3080_OpenIC_BQY_{filename} Open randomly selected BQY in Plugin 3090_ProcessIC_BQY_{filename} (*) Process opened BQY 3100_BQY_Jobs_Folder Open BQY jobs folder 3110_BQY_Subfolder Open BQY jobs subfolder 3120_PublishBQY_Step1(*) Click on Publish file 3130_PublishBQY_Step2(upload)_{filename}(*) Specify file to be published 3140_PublishBQY_Step3(next) _{filename} (*) Specify connectivity 3150_PublishBQY_Step4(finish) _{filename} (*) Click on Finish 3160_PublishBQY_Step5(refresh)_{filename}(*)

Refresh content

3170_Delete_BQY (*) Delete just published BQY file 3110_Exit Logout

(*) 10% of all Intelligence Client users executed these actions. {filename} represents a randomly selected BQY file with the 1,000-, 10,000-, or 100,000-row query.


Hyperion Interactive Reporting 11.1.1 Capacity Planning Report for Windows May 2009 Author: Katherine Hagedon Contributing Author: Nikolai Potapov 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 2009, 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.

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 300 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile () /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/Description > /Namespace [ (Adobe) (Common) (1.0) ] /OtherNamespaces [ > /FormElements false /GenerateStructure true /IncludeBookmarks false /IncludeHyperlinks false /IncludeInteractive false /IncludeLayers false /IncludeProfiles true /MultimediaHandling /UseObjectSettings /Namespace [ (Adobe) (CreativeSuite) (2.0) ] /PDFXOutputIntentProfileSelector /NA /PreserveEditing true /UntaggedCMYKHandling /LeaveUntagged /UntaggedRGBHandling /LeaveUntagged /UseDocumentBleed false >> ]>> setdistillerparams> setpagedevice

interactive reporting capacity planning report - ir 11.1.1 windows

Documents

capacity planning report

hyperion interactive

test configuration

different test scenarios

heap sizes

windows executive overview

workspace web heap settings

oracle white paper