Using zEnterprise for Smart Analytics: Volume 1 Assessment

90 Using zEnterprise for Smart Analytics: Volume 1 Assessment

Whenever possible, verify actual results against projected results; that is, undertake the

classic “before and after” comparison. The goal is to show that the base capacity planning

(when from one z architecture-based server to another z architecture-based server) or a

specific consolidation sizing projection is allowing the system to run within the expected levels

of performance.

Tuning can also be part of the process. It targets the optimization of the system to enable it to

run as efficiently as possible. If tuning is required, it is helpful to modify only a single

parameter at a time. After the change, the consequences of this specific change need to be

evaluated. After the consequences of the first targeted individual tuning are fully understood

in terms of its impact to the system, then (and only then) you can move to change the next

parameter. Iterate until no more parameters are left to be changed. “Bulk” (simultaneous)

changes are not helpful because they do not enable you to understand the cause and effect

of these changes. Unraveling the interdependent effects of multiple changes can be difficult

and sometimes impossible.

The goal of understanding the “before and after” situations, whether by capacity planning (z to

z) or through sizing (consolidation or new workload), is to better understand the results,

validate the input, better forecast future growth, and create a larger database of real cases to

be fed back to development. This process enables each of us to participate in the

enhancement of existing tools and methodologies.

We have described many versions of sizing and capacity planning processes. Keep in mind

that from this point on, when we refer to sizing, that will be a reference to the process that

handles sizing of a new application. The sizing description that follows will be an

example of a

scenario, similar to the Banking Smart Analytics scenario we are implementing.

The example that follows is only to illustrate the process. The input numbers used and the

results produced do not map against the real implementation described in other chapters of

this book, nor in other related volumes.

10.5.4 Cognos 10 BI sizing for Linux on System z: Input

The process to size Cognos 10 BI for Linux on System z is well established. When targeting

the System z architecture, it is a two-step process that we explain later in this section. It is

recommended that you seek IBM’s support for help with these tasks.

The sizing guidelines are based on IBM internal testing and real-life experience. Successful

sizing guidelines are always developed in collaboration between a qualified client and IBM

Cognos representatives. By working together, we ensure the proper interpretation of the

information collected throughout the client interview process and the correct application of

Cognos 10 sizing methodology.

Sizing input data

You need to gather the following types of information to enable the Cognos 10 BI for Linux on

System z sizing:

򐂰 User roles

򐂰 User concurrency

򐂰 Use of portlets and Business Insight Consumer dashboards (BIC)

򐂰 Solution access patterns

򐂰 Application complexity

򐂰 Query complexity

򐂰 Output complexity

򐂰 Percentage of overall BI content for heterogeneous query

򐂰 Percentage of overall BI content for master/detail query

Chapter 10. Stage 6: Sizing and capacity planning 91

򐂰 Percentage of overall BI content using personal data merge

򐂰 Percentage of overall BI content Dimensionally Modeled Relational (DMR) data query

򐂰 Percentage of overall BI content for statistics

򐂰 Batch report processing requirements

򐂰 IBM Power Cube® building requirements

򐂰 Technology preference

򐂰 Deployment option

As you can see, there are many areas required to be part of the input to produce the proper

Cognos 10 BI sizing. Some of these entries are only the top header of many sub-items.

Describing all the entries here is beyond the scope of this book. However, we chose a few

areas to illustrate the level of the input requirement.

User roles

The idea behind asking the client to define user roles is to provide the required granularity to

enable you to differentiate ratings of concurrent users based on different user roles. Examples

of user roles are illustrated in Figure 10-7.

Figure 10-7 Types of Cognos 10 BI users

Application complexity

No two client applications are exactly alike. To produce a proper sizing, you have to provide a

simplified measure of projected or existing application complexity, described in a number of

areas. In each area, application complexity is expressed through four categories: simple,

intermediate, extended, and highly extended. Figure 10-8 on page 92 illustrates an example

of query complexity parameters.