You are on page 1of 7

3/8/2017 Document 1075678.


Estimating Infrastructure Size for Oracle Hyperion Essbase (Doc ID 1075678.1)

In this Document



Hyperion Essbase ­ Version and later
Information in this document applies to any platform.


The purpose of this document is to provide guidance estimating infrastructure specifications for Essbase.


There is no replacement for systematic testing to determine the specific hardware specifications required to support Essbase,
no matter how hard the shoe strikes the podium. We think that everyone knows that this is true. And it is also true that at the
very beginning of a new development initiative, the proverbial cart is before the horse. How does one define hardware
specifications for processing requirements that are not yet quantified? The short answer is that you cannot. 

In the absence of requirements, every estimation for hardware is based on assumptions.

Essbase Server Assessments 
We frame the sizing discussion by briefly presenting how we evaluate existing Essbase servers when processing requirements
are fully understood. When the results of the assessment reveal that the infrastructure is found wanting, an estimation of more
appropriate server specifications can be brought forward. The criteria used to draw up these new specifications forms an ideal
list of criteria for assessing Essbase infrastructures. 

Once ideal requirements are understood, you will be able compare them to what is available on more generic assessments.
Subtracting the generic criteria from the ideal gives an indication of how accurate the sizing estimate can be expected to be.

Assessment Checklist 
The following is a summary list of the objects and information that eServices review in order to complete an Essbase
infrastructure server assessment: 

1. Essbase Server Configuration 
    a. Essbase.cfg Settings 
2. Essbase Application Settings 
    a. Application Logs 
    b. Cube Outlines 
    c. Cube Statistics 
    d. Calc Script/Business Rules Procedural Logic and Settings 
    e. Batch Process Scripts 
3. Hardware Server Configuration 
    a. Operating System 
    b. Processors 
        i. number 
        ii. speed 
        iii. architecture 
    c. RAM 
    d. Virtual Machine configuration 
    e. LPAR definition 
    f. Server Application profile­state=xzugvxkj4_613&id=1075678.1 1/7

 a more reliable determination of hardware requirements can be made.  To sum operating system and supporting infrastructure components are behaving. Supporting Infrastructure Components  The Essbase configuration and script settings are cross­referenced with infrastructure settings and configuration.  This type of measurement makes it possible to assess server behavior. in situ infrastructure assessments analyze detailed Essbase and infrastructure metrics to determine how and why the infrastructure is responding to specific Essbase processing requirements. and can be incorporated to provide accurate infrastructure specification criteria.  When disks were busy. CPU. Requests for processor.  In an in situ environment. This usually stands far outside of what is possible to do within the timeframes allocated for an assessment. Sometimes a tuning effort is sufficient to enable the system to perform up to service level agreements. Essbase Optimization  Every Essbase server review should look at the Essbase cube designs to determine whether they are following best practices. The first two items really provide specific sizing criteria for hardware. An analysis is made of Essbase design characteristics. From this we were able to see the disk bottleneck and the impact that it was having on CPU utilization. Server Performance Monitoring Logs      a. 2 and 3 are already working together. These infer specifications for hardware listed in item 3.ctrl­state=xzugvxkj4_613&id=1075678. tuning is mandatory because it averts the criticism that hardware is simply being thrown at the problem.  Once. however. RAM      b.  Consider the attachment of two charts created during an infrastructure assessment. They show the saw tooth behavior of both disk and CPU activity. and subjected to analysis.  In our opinion. etc.3/8/2017 Document 1075678. The activities being measured were data load and aggregation batch process routines. items 1. CPU      c. and sometimes not.  Infrastructure Analysis  Concurrency is accurately extracted from the Essbase performance logs by identifying overlapping response times. Full reviews vary in no significant way from an implementation in terms of the amount of time and resources that they consume. and have specific content. CPUs became idle. Response times are combined manually to provide a single Essbase Performance Log. The analysis of Essbase settings and processing requirements enables an accurate estimation of hardware should the current infrastructure be https://support.1 2/7 . and vice versa. Comparing teeth directly. Disk configuration      h. network and disk resources are extracted from the Essbase Application logs in the form of response times for events. clearly evident is an inverse relationship between disk and CPU. Network configuration  4. Vertical lines have been inserted to illustrate. The accuracy of the sizing estimate is strictly correlative with the accuracy of these assumptions. and so on).) is monitored and measured during Essbase processing.  Correlating the Server Performance Monitoring Logs with Essbase events.1     g.  Complete application design reviews involve coordinating the detailed business requirements with cube design decisions. The infrastructure (RAM. Network      d. A sizing assessment where software requirements are minimally known means that assumptions need to be provided. Assessment Components  Essbase Server  Essbase objects are analyzed for settings (caches. Disk  Items 1 and 2 contain detailed software requirements. enable you to compare what is being allocated to Essbase processes with how the underlying server hardware. and whether tuning methodologies can be invoked to increase performance. The contents of the manually generated Essbase performance log are correlated with infrastructure performance log statistics. the cubes and their processes have been optimized within time and resource constraints. and tuning techniques are applied to ensure that Essbase processes are as efficient as possible.

g. or virtual environments. an individual cube might need to be provided dedicated storage. RDBMS). It is not possible to predict the impact of a change in one architecture based on the impact that the change has on an architecturally different one. Concurrency analysis can of course be applied to any infrastructure resource. Logical partitions (LPARs). Every infrastructure estimation is based upon an explicit or implicit model of what the use cases will actually be. Generic Infrastructure Recommendations  Production performance issues invariably are the result of process contention for the same hardware of course. Performance engineering software simulations should be used to determine optimal hardware settings to support the Essbase server. So QA needs to be a duplicate of Production. Purchase in Stages  Ideally you will design your system to have three environments: Development. disk. Minimize memory conflicts by ensuring that processes have sufficient RAM resources to complete without the OS having to use virtual memory space. Minimize storage I/O conflicts between Essbase and other 3rd party applications (e.1 3/7 . concurrency eventually means the simultaneous request for processor resources.  High­level and generic recommendations for infrastructures designed to support Essbase are:  1. or performance testing. We can talk about concurrency as it applies individually to memory.  https://support.3/8/2017 Document 1075678. and intra­cube I/O contention (e. 3. multiple business rules.  The Development environment is not used for QA. must be able to be controlled so that the Administrator is sure that each Essbase process has full access to the resources being assigned to it. It only needs to be configured to enable developers to do their work capturing user business requirements.  In this way. the degree of this contention. a complete list of Essbase settings and processing requirements are requisite to estimating infrastructure requirements. We promote that you begin by investing in a Development environment. Develop in Stages.  This observation is accurate because of the strict demands of change network. And because QA needs to be as close to identical with Production as possible. Opting to use a single box for Development and QA locks you in a paradox: You need to estimate your Production infrastructure specifications before you know your Production infrastructure requirements. and the batch processes required to support them start to be understood. the hardware configurations required to support processing requirements start to be objectified. a Development environment helps empirically to define the requirements for a QA. 2. exporting. between different Essbase applications.  Generic recommendations for methodologies to determine system requirements:  1. business requirements are modeled. it is good practice to ensure that Essbase uses dedicated devices for storage. Through the iterations of the development process. you are comfortable faking it.  In the final analysis. Essbase vs.ctrl­state=xzugvxkj4_613&id=1075678. During the initial development phase. querying and aggregating. In demanding Essbase environments.g.  When attempting to estimate requirements to support Essbase Server. And the overall concurrency that any given system is able to support is determined by the throughput of the entire software and hardware infrastructure. In extremely demanding processing situations. or estimate. We measure.  Unless. Methods for Estimating  We want to recommend not to purchase Production hardware before Production user (software and business) requirement details are known. etc. It is not too inaccurate to think of bottlenecks essentially as where the concurrency rubber hits the infrastructure road. CALCPARALLEL and queries). Test/QA and Production. Performance engineering software simulations should be used to determine the optimal Essbase settings to support loading.  2. processor.1 found wanting. We do not know of any way to estimate hardware specifications for requirements that are not quantified in some tangible way. Minimize processor related variations in performance by configuring Essbase to run using dedicated resources. the QA infrastructure defines what is required for Production. and refer to it as concurrency.

 the concurrency estimate of 30 turns out to be very large indeed. we have an application where slightly less than 30 * 5 more processing requests have been generated. for example. the number of concurrent requests that are going being made of the processors. concurrency is best understood within the context of peak usage factored by response time. an estimated concurrency of 30. It is a perfectly legitimate way to begin to think about concurrency. Using one second as the default interval is useful because it simplifies an accurate estimation of concurrency. The test was able to be run for slightly less than 30 minutes. The average response time jumped from 25 to over 450 seconds before having to be stopped. We write inaccurately because we mean that concurrent requests theoretically are occurring whenever we snapshot the Essbase Server. and the number of users for a system is available very early in the application lifecycle. peak usage now means "every second for four continuous hours. 30 new requests for processor are being made by users.  For example. completely unresponsive.  What kind of server can reasonably be expected to be able to perform under such a workload? Definition of Concurrency  We broaden the definition of concurrency to be "the number of requests for processor that can occur within an average response time.  In our example.  Peak usage specifies concurrency across a period of time.ctrl­state=xzugvxkj4_613& 30 simultaneous requests are being made for processor". and add to that the duration of 4 hours. The average baseline query response time (~25 seconds) was measured before and then during while increasing workload demands were made of the server. we recently reviewed a customer environment for performance. This is important because Essbase performance is invariably determined by a combination of the three characteristics of simultaneous requests. Concurrency and Essbase  The classic way that concurrency is estimated derives from the total number of users of the system. Ten percent (10%) appears to be the de facto standard used for this driver. let us inaccurately define "simultaneous" as a one second interval. Sadly.  In terms of Essbase." This helps delineate the relation between response time and concurrency: Concurrency varies directly with response time. peak usage and response time.  How accurate is this for helping to size Essbase infrastructures? Recalling the above definition of concurrency as the "simultaneous request for processor". in precise detail.  How would this scenario have been described if this were an actual Production run rather than a simulation? "We saw more or less acceptable performance for a few minutes this morning before the entire system became totally. The result is that we have a queue of just under 150 requests occurring within the first 5 seconds of peak runtime. When we factor the average response time for these requests.1 When not able to perform a concurrency analysis using accurate simulations of end­user activities. Processor Concurrency  When thinking about defining a server infrastructure for Essbase. And this activity is expected to happen for four solid hours. it is possible for an improperly configured Essbase Server environment to overwhelm powerful server infrastructures. We are looking to understand.  If we take our figure of 30 simultaneous requests. at any point in time during our peak 4 hour period." Hopefully that comment is not familiar to very many 4/7 . we end up with something like "peak usage for Essbase is that.000 named users represents 300 connected users and." If the average response time is in the order of 5 seconds (and five seconds is a very optimistic response time given the current trend of customer uses of Essbase). The connected user count was only ~5% of the actual anticipated connected user volume. sizing must be performed using estimates for concurrency. 3.3/8/2017 Document 1075678. then we have a potential problem because by the time that the first 30 requests have been processed. and the connected user count is factored by another (perhaps the same?) driver to estimate concurrency. we begin to develop a conceptual framework for defining an infrastructure to support concurrency. it is necessary to conceive concurrency as having two https://support. and for the length of time that these requests are expected to occur. How does response time factor into this?  For the sake of discussion. ultimately. So.  The number of total users is factored by a driver to estimate the number of connected users. This is probably because it is easy.

 end user activities are temporarily suspended. Essbase systematically reads data in.. aggregation creation) is where the Administrator designs how Essbase computes and stores cube values in the effort to enhance query responsiveness. Failure during peak periods will undermine user confidence in the entire application. both the average response time and concurrency increase. https://support. when the number of requests for processor is high. however. Running Batch in Isolation  When the batch processes are being run isolated..  The worst case for customers occurs when requests are so high as to dramatically reduce the number of available processors per request.orgwiki/Concurrency_(computer_science)  ) When either the number of requests for processor or the average response time is under­estimated. requests for processor  2. calculates/aggregates. This explains how concurrency and performance vary over time. and writes data out.Concurrent use of shared resources can be a source of indeterminacy leading to. however. Computing and persisting data is demanding of processor.starvation. the accuracy of the proposed infrastructure specifications is undermined. on the other hand. During peak periods. Running Batch in Parallel  Running in parallel means batch processes are run coincident with end­user activities. however. Response times become so attenuated that the entire application becomes the number of requests for processor is low. sometimes for extended (hours) periods of time. From the user perspective. network and disk resources: During aggregation creation. end user downtime is becoming less and less tolerable for enterprise analytic applications..3/8/2017 Document 1075678.e. average resulting response times are low. Meta data and data are updated and then data is pre­ processed before being made available to users. processor concurrency refers to the number of requests that occur within the average peak response time. and so too is concurrency. Isolating events in time is the easiest way to ensure that the resources that are required to perform the batch processes are available without restriction. Understanding Essbase Processes  Batch Processing   There are two components to Essbase batch refresh processes. the number of possible execution paths in the system can be extremely large. be the expected behavior:  "Because computations in a concurrent system can interact with each other while they are executing. average response time  We are tempted to construct the following formula for computing concurrency:                                           Concurrency = Requests * Response_Time  At the level of understanding desired This minimizes the impact on the end user. From an infrastructure perspective what is required is that the server be configured with sufficient resources to process the batch routines efficiently.1 characteristics:  1.. Whereas this involves a minimal requirement for hardware. The architecture is configured with sufficient resources to enable efficient batch processing without any significant degradation in performance of end user activities. Pre­processing (i.  Peak usage always coincides with the delivery of critical functionality.ctrl­state=xzugvxkj4_613&id=1075678.  The unresponsiveness might.  Underestimating resources here has two unfortunate characteristics; most of the time the system appears under utilized.  Resource demands and best practices require that batch processing be carried out in isolation from end­user query activity.1 5/7 . the whole system becomes a bottleneck for batch as well as user processes. Batch routines are usually run this way so that the Admin can be sure that required server resources are able to be allocated to specific Essbase processes. it means that there is potentially a significant period of time when the application is not available."  (source http://en. During times of peak use. but it maximizes infrastructure requirements. In this scenario there are possibly great periods of time when the infrastructure is under utilized.  During non­peak periods.

1 Query Processing  The quality of the end­user experience of Essbase is defined by query performance characteristics. Where it is not possible https://support. This is achieved different ways.  For an Aggregate Storage Option cube. To take advantage of the performance gains from multiple­core technologies. Storage Requirements  Oracle will recommend customers use dedicated storage whenever possible for Essbase. The result can be. Whereas these configurations are supported by Oracle for Essbase. the query response time bottom line is reached. so single FPU processors represent a bottleneck for Essbase. for some applications. and that it is not possible to predict accurately how any given cube will respond to this technology.3/8/2017 Document 1075678. This way. it is best to test to determine what is appropriate for your Essbase environment. to improve throughput by as much as ~30%. and often demonstrates degraded performance. LPAR/VM Definitions  Virtual machine and some LPAR definitions of Essbase servers are being used to share resources. the OS perceives twice as many logical CPUs as there are physical ones. However. If all the EPM components are on one physical server then use a corresponding server network connection up to the maximum speed of the network throughput of routers to the network. Using separate physical drives and I/O channels for the location of these files. additional throughput performance gains are achieved by splitting Block Storage Option applications to calculate and store the index and data files on different physical drives and controllers. you can reduce I/O contention and there by improve overall performance. the nature of a shared environment is such that it is technically challenging to control server resources to ensure especially what processor resources are being allocated to Essbase. or both. data is stored in both the Temp and Default directories during data load and aggregation processing.  Essbase performance is. Bigger and faster hardware is augmented by scaling the environment horizontally across multiple different servers. Considering that there are platform implementation differences. A small number of customers anecdotally report increased responsiveness using multi­processor simulations. Multiple Cores and Floating Point Units (FPU)  This is perhaps an outdated topic because of recent trends in processor technologies.1 6/7 . at some point. Network Speed and Bandwidth  Using a full duplex 1GB Network connection between any servers in the same zone that have EPM components that communicate is optimal. application and cube dependent. or by scaling the environment vertically on dedicated fiber connections will be very beneficial. Query performance depends upon three factors:   CPU availability ­ a query is a single threaded event and thus requires one CPU   Query Size ­ the amount of data that Essbase is required to retrieve from disk  Dynamic Processing ­ the number and degree of dynamic computations  The objective of developing an efficient Essbase computing environment is to create one where the resource requirements to support batch processes are not simultaneously competing for resources required for end­use querying. Breaking up the Aggregate .  Not all software applications are enhanced by the use of these technologies. Many times performance limitations on Essbase will be Disk as well as CPU related.ctrl­state=xzugvxkj4_613&id=1075678. Applications calculating and reporting data which will drive high I/O utilization on a storage system. For SAN devices. Tuning the cube to have more efficient response times mitigates this. This configuration will be helpful specifically when calculating multiple applications simultaneously.DAT files by storing large databases on different physical drives with different I/O channels can also improve query performance. In general it has been found that Essbase performance is not enhanced. Large queries that take minutes to complete have a much greater chance of being concurrent with other processing requests. Other Performance Related Considerations Multi­Threading Technologies  Multi­Threading processor technologies spawn two threads per physical CPU to emulate multiple processing While not necessary. however. The result is that Essbase performance characteristics cannot be controlled to deliver a consistent level of performance. ensure that each core is configured with its own FPU. Essbase performs floating point arithmetic. and hardware appears as the only way to increase performance.

 Memory is allocated by adding 2GB of RAM to the server for each core.ctrl­state=xzugvxkj4_613&id=1075678. here are two methods that can be used. When use­case scenarios are not well known. using batch concurrency and query response time assumptions. we recommend that you decide against using Essbase in a shared environment.e. Adding to the overall complexity of using this method is to keep in mind how important report design is for performance. Add an additional core for each report that runs for 60 seconds or more. To this base number of cores. Estimating Core and RAM Requirements  If the requirement persists to estimate infrastructure specifications without processing requirement details being known. expensive) estimates for core and RAM requirements. but potentially expensive. In large computing environments. 25 Users Per Core  This method assumes a desired 15 second response time for queries/reports where minimal increases in response times are required. For an application that batch routines are run in isolation.  The examples assume that batch routines are run in parallel with end­user Users per Core  Another option is to base the number of cores on the number of users. Processor Cores per Application based on Active Users  This method is easy.  The examples that follow are experienced estimates that can only be validated with realistic load testing. RAM estimation allocates between 2 and 4 GB of RAM per application rather than per core. this can easily lead to very pessimistic ( add the number of cores required for parallel batch processing to compute the total number of estimated cores. 50 Users Per Core.3/8/2017 Document 1075678. Both make assumptions about how to gauge concurrency.  The method assumes a desired 15 second response time for queries/reports with the longest query taking no longer than 30 seconds.1 to be sure that the server will be able to meet the end­user service level agreements. The second includes adding cores to support batch processing requirements and factors in a desired response time for end user querying. Didn't find what you are looking for? https://support.1 7/7 . To this base number. core estimates should be reduced accordingly. estimate processor and memory requirements the following way: Allocate six cores per Essbase application.  The use­case scenario that this rule was devised for is an Essbase and Relational reporting environment with 2000 named users where 500 users are active. you add cores required for parallel batch processing. RAM and core requirements.