Infrastructure Sizing for Essbase (part 1)

This is the first of a series of three blog entries where we discuss estimating infrastructure specifications to support Essbase.


John French
ACS Principal Service Delivery Engineer

Richard (Rick) Sawa
ACS Principal Service Delivery Engineer


Overview
We provide a high-level discussion of what is involved in assessing/sizing a server infrastructure to support Essbase. We start by briefly outlining the requirements and procedures involved with assessing an existing environment. This establishes a frame of reference for the discussion that follows on guidelines for estimating infrastructures to support Essbase when the details of end-user and batch processing requirements have yet to be defined.

Introduction
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’s 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 can’t.

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 (number, speed & architecture)
c. RAM
d. Virtual Machine configuration
e. LPAR definition
f. Server Application profile
g. Disk configuration
h. Network configuration
4. Server Performance Monitoring Logs
a. RAM
b. CPU
c. Network
d. Disk

Items 1 and 2 contain detailed software requirements. These infer specifications for hardware listed in item 3. The first two items really provide specific sizing criteria for hardware.

In an in situ environment, items 1, 2 and 3 are already working together, and have specific content. A sizing assessment where software requirements are minimally known means that assumptions need to be provided. The accuracy of the sizing estimate is strictly correlative with the accuracy of these 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.

Once, however, the cubes and their processes have been optimized within time and resource constraints, a more reliable determination of hardware requirements can be made. Sometimes a tuning effort is sufficient to enable the system to perform up to service level agreements, and sometimes not.

In our opinion, tuning is mandatory because it averts the criticism that hardware is simply being thrown at the problem.

Supporting Infrastructure Components
The Essbase configuration and script settings are cross-referenced with infrastructure settings and configuration. The infrastructure (RAM, CPU, etc.) is monitored and measured during Essbase processing.

Infrastructure Analysis
Concurrency is accurately extracted from the Essbase performance logs by identifying overlapping response times. The contents of the manually generated Essbase performance log are correlated with infrastructure performance log statistics, and subjected to analysis.

Correlating the Server Performance Monitoring Logs with Essbase events, enable you to compare what is being allocated to Essbase processes with how the underlying server hardware, operating system and supporting infrastructure components are behaving.

Consider the two following charts created during an infrastructure assessment. They show the saw tooth behavior of both disk and CPU activity. Comparing teeth directly, clearly evident is an inverse relationship between disk and CPU. Vertical lines have been inserted to illustrate:


When disks were busy, CPUs became idle, and vice versa. The activities being measured were data load and aggregation batch process routines. From this we were able to see the disk bottleneck and the impact that it was having on CPU utilization.

This type of measurement makes it possible to assess server behavior, and can be incorporated to provide accurate infrastructure specification criteria.

To sum up, in situ infrastructure assessments analyze detailed Essbase and infrastructure metrics to determine how and why the infrastructure is responding to specific Essbase processing requirements. An analysis is made of Essbase design characteristics, and tuning techniques are applied to ensure that Essbase processes are as efficient as possible. The analysis of Essbase settings and processing requirements enables an accurate estimation of hardware should the current infrastructure be found wanting.

In the final analysis, a complete list of Essbase settings and processing requirements are requisite to estimating infrastructure requirements.
________________________________________

Next week we will continue with a general discussion sizing concepts and focusing on how to best understand concurrency and Essbase.