Forum Stats

  • 3,782,418 Users
  • 2,254,643 Discussions
  • 7,880,075 Comments

Discussions

Recommended Processor Speeds for Hyperion 11.1.1.3 on IBM P6 Machine

731163
731163 Member Posts: 40
edited Jan 26, 2012 10:22PM in EPM System Infrastructure
Hi ,
Is the any way to calculate the required processor speeds for Hyperion 11.1.1.3 for 50 users on an IBM P6 Machine? The documentation only gives details of the required RAM and Disc space that is required. Any help in this matter would be highly appreciated..

Best Answer

  • John A Booth
    John A Booth Member Posts: 1,508
    edited Jan 26, 2012 10:22PM Accepted Answer
    Generally for a Power 6 Machine look at between two and four cores depending on what type of load will be on the system.

    Presuming this will host Essbase a faster clock speed is always better -- the Power 6's have a pretty nice clock speed when compared to just about any other vendor processor so don't stress too much on a perfect clock speed.

    Regards,

    John A. Booth
    http://www.metavero.com

    Edited by: John A. Booth on Jan 26, 2012 7:20 PM
    Added the comment re clockspeed.

Answers

  • Vasavya Chowdary
    Vasavya Chowdary Member Posts: 1,088
    edited Jan 8, 2012 10:42PM
    The requirements are made on every estimation for hardware is based on assumptions.


    Assessment Components
    Essbase Server
    Essbase objects are analyzed for settings (caches, CALCPARALLEL, and so on). Requests for processor, network and disk resources are extracted from the Essbase Application logs in the form of response times for events. Response times are combined manually to provide a single Essbase Performance Log.

    Essbase Optimization
    Every Essbase server review should look at the Essbase cube designs to determine whether they are following best practices, and whether tuning methodologies can be invoked to increase performance.

    Complete application design reviews involve coordinating the detailed business requirements with cube design decisions. Full reviews vary in no significant way from an implementation in terms of the amount of time and resources that they consume. This usually stands far outside of what is possible to do within the timeframes allocated for an assessment.

    Running Batch in Parallel
    Running in parallel means batch processes are run coincident with end-user activities. The architecture is configured with sufficient resources to enable efficient batch processing without any significant degradation in performance of end user activities. This minimizes the impact on the end user, but it maximizes infrastructure requirements. In this scenario there are possibly great periods of time when the infrastructure is under utilized.

    Underestimating resources here has two unfortunate characteristics; most of the time the system appears under utilized. During times of peak use, however, the whole system becomes a bottleneck for batch as well as user processes.

    Peak usage always coincides with the delivery of critical functionality. Failure during peak periods will undermine user confidence in the entire application.

    Query Processing
    The quality of the end-user experience of Essbase is defined by query performance characteristics. 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. Large queries that take minutes to complete have a much greater chance of being concurrent with other processing requests. Tuning the cube to have more efficient response times mitigates this. However, at some point, the query response time bottom line is reached, and hardware appears as the only way to increase performance. This is achieved different ways. Bigger and faster hardware is augmented by scaling the environment horizontally across multiple different servers, or by scaling the environment vertically on servers, or both.

    Storage Requirements
    Oracle will recommend customers use dedicated storage whenever possible for Essbase. Many times performance limitations on Essbase will be Disk as well as CPU related. Applications calculating and reporting data which will drive high I/O utilization on a storage system. For SAN devices, dedicated fiber connections will be very beneficial. This configuration will be helpful specifically when calculating multiple applications simultaneously. While not necessary, 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.

    For an Aggregate Storage Option cube, data is stored in both the Temp and Default directories during data load and aggregation processing. Using separate physical drives and I/O channels for the location of these files, you can reduce I/O contention and there by improve overall performance. Breaking up the Aggregate .DAT files by storing large databases on different physical drives with different I/O channels can also improve query performance.

    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.
    Multi-Threading processor technologies spawn two threads per physical CPU to emulate multiple processing cores. This way, the OS perceives twice as many logical CPUs as there are physical ones. The result can be, for some applications, to improve throughput by as much as ~30%.


    Processor Cores per Application based on Active Users
    This method is easy, but potentially expensive. When use-case scenarios are not well known, estimate processor and memory requirements the following way: Allocate six cores per Essbase application. Memory is allocated by adding 2GB of RAM to the server for each core.

    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. In large computing environments, this can easily lead to very pessimistic (i.e. expensive) estimates for core and RAM requirements.

    Users per Core
    Another option is to base the number of cores on the number of users, using batch concurrency and query response time assumptions. RAM estimation allocates between 2 and 4 GB of RAM per application rather than per core.

    The examples that follow are experienced estimates that can only be validated with realistic load testing. Adding to the overall complexity of using this method is to keep in mind how important report design is for performance, RAM and core requirements.

    50 Users Per Core.
    The method assumes a desired 15 second response time for queries/reports with the longest query taking no longer than 30 seconds. To this base number of cores, you add cores required for parallel batch processing.

    25 Users Per Core
    This method assumes a desired 15 second response time for queries/reports where minimal increases in response times are required. Add an additional core for each report that runs for 60 seconds or more. To this base number, add the number of cores required for parallel batch processing to compute the total number of estimated cores.

    Edited by: Vasavya on Jan 9, 2012 10:36 AM
    Vasavya Chowdary
  • John A Booth
    John A Booth Member Posts: 1,508
    edited Jan 26, 2012 10:22PM Accepted Answer
    Generally for a Power 6 Machine look at between two and four cores depending on what type of load will be on the system.

    Presuming this will host Essbase a faster clock speed is always better -- the Power 6's have a pretty nice clock speed when compared to just about any other vendor processor so don't stress too much on a perfect clock speed.

    Regards,

    John A. Booth
    http://www.metavero.com

    Edited by: John A. Booth on Jan 26, 2012 7:20 PM
    Added the comment re clockspeed.
This discussion has been closed.