...

Understanding IBM Cognos 8 PowerPlay Performance Guideline Product(s): IBM Cognos 8 PowerPlay

by user

on
Category: Documents
1

views

Report

Comments

Transcript

Understanding IBM Cognos 8 PowerPlay Performance Guideline Product(s): IBM Cognos 8 PowerPlay
Guideline
Understanding IBM Cognos 8
PowerPlay Performance
Product(s): IBM Cognos 8 PowerPlay
Area of Interest: Performance
Understanding IBM Cognos 8 PowerPlay Performance
2
Copyright and Trademarks
Licensed Materials - Property of IBM.
© Copyright IBM Corp. 2010
IBM, the IBM logo, and Cognos are trademarks or registered trademarks of
International Business Machines Corp., registered in many jurisdictions worldwide.
Other product and service names might be trademarks of IBM or other companies. A
current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/
copytrade.shtml
While every attempt has been made to ensure that the information in this document
is accurate and complete, some typographical errors or technical inaccuracies may
exist. IBM does not accept responsibility for any kind of loss resulting from the use
of information contained in this document. The information contained in this
document is subject to change without notice.
This document is maintained by the Best Practices, Product and Technology team.
You can send comments, suggestions, and additions to [email protected]
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.
Understanding IBM Cognos 8 PowerPlay Performance
3
Contents
1
INTRODUCTION..............................................................................................4
1.1
1.2
1.3
PURPOSE..................................................................................................................4
APPLICABILITY.............................................................................................................4
EXCLUSIONS AND EXCEPTIONS...........................................................................................4
2
BACKGROUND INFORMATION....................................................................... 4
2.1
2.2
2.3
2.4
OVERVIEW................................................................................................................4
ARCHITECTURE AND REQUEST FLOW
5
COMPARISON WITH OTHER COGNOS 8 SERVICES......................................................................6
ADMINISTRATIVE SETTINGS AND MIGRATION...........................................................................7
3
HIGH/LOW AFFINITY CONNECTION SETTINGS............................................ 7
3.1
3.2
3.3
UNDERSTANDING THE NUMBER OF HIGH/LOW AFFINITY CONNECTION SETTINGS................................... 7
HIGH/LOW AFFINITY CONNECTION SETTINGS AND IBM COGNOS POWERPLAY CLIENT CONNECTIONS............9
HIGH/LOW AFFINITY CONNECTION SETTINGS RECOMMENDATIONS...................................................9
4
POWERCUBE READ CACHE........................................................................... 10
4.1
4.2
4.3
UNDERSTANDING POWERCUBE READ CACHE SETTINGS..............................................................10
SETTING PPDS CACHE SETTINGS....................................................................................10
PPDS CACHE SETTINGS RECOMMENDATIONS......................................................................... 11
5
MONITORING AND TUNING.........................................................................11
Understanding IBM Cognos 8 PowerPlay Performance
4
1 Introduction
1.1
Purpose
This document is intended to provide IBM Cognos Series 7 PowerPlay
administrators an overview of the tuning mechanisms in place for IBM
Cognos 8 PowerPlay.
1.2
Applicability
This document applies to:
 IBM Cognos PowerPlay 8.4 27.27
1.3
Exclusions and Exceptions
Although some contents of this document may apply to an environment that
houses both IBM Cognos 8 PowerPlay content and content form other IBM
Cognos 8 BI components; this document is geared for IBM Cognos 8
PowerPlay content only.
2 Background Information
2.1
Overview
The IBM Cognos 8 service-oriented architecture makes possible the
integration of IBM Cognos PowerPlay into the IBM Cognos 8 environment.
This integration provides a lower cost of ownership while enhancing the
capabilities of IBM Cognos PowerPlay and maintaining the same product feel
that is know to existing users. Among the benefits, this architecture:




allows the PowerPlay service in the IBM Cognos 8 environment to
continue to use the same query engine as in IBM Cognos Series 7. As
a result, IBM Cognos PowerPlay reports and cubes, migrate easily into
the IBM Cognos 8 environment.
adds PowerPlay as an IBM Cognos 8 studio and allows existing IBM
Cognos 8 studios to open PowerPlay reports. This allows report
authors to work with a familiar interface to produce reports and
leverage the features of other IBM Cognos 8 studios.
allows for drill through from IBM PowerPlay Studio to other existing
IBM Cognos 8 studios.
provides a single access point for all IBM Cognos 8 administration
settings within the IBM Cognos Administration zero-footprint Webbased interface.
Understanding IBM Cognos 8 PowerPlay Performance
2.2
5
Architecture and Request Flow
An incoming HTTP request is received by the Cognos 8 gateway and handed off to
the load balancing C8 Dispatcher (if one exists). In Series 7, PowerPlay had its own
gateway. In Cognos 8, all components use a common gateway – Cognos.cgi. The
load balancing dispatcher will receive the request and will then find a C8 dispatcher
(request processor) to process this request based on a weighted round robin
algorithm, and will then send a BIBUS request to the selected C8 dispatcher.
Once a dispatcher has been identified to process the request, it will receive the
BIBUS request and look for a connection to pass the request to the PPESBusServer.
If all connections to the PPESBusServer are busy (See Affinity section), the request
will go into a queue where it waits for the next available connection. When requests
are queued, a connection becomes available when a previous request has
completed. PPESBusServer is a thin wrapper around the BIBUSTKServer process,
and contains the PPES plug-in, which is the equivalent of the Series 7 PPES
Dispatcher.
Understanding IBM Cognos 8 PowerPlay Performance
6
The PPES Plug-in calls QECL to get credential information. QECL is the component
that IBM Cognos PowerPlay uses to store session information, such as credential and
data source connection information. The PPES Plug-in then passes the request off to
a ppdsweb.exe (query processor or QP) or pprp.exe (report processor or RP). An RP
processes PDF reports in Client layout, where all other PowerPlay 8 requests are
processed by the ppdsweb process. The ppdsweb and pprp processes perform the
same functions in IBM Cognos PowerPlay 8 as they did in IBM Cognos Series 7
PowerPlay. If the maximum number of QP’s or RP’s is already in use, then the
request will go into a queue (different from the above mentioned queue).
The QP receives and parses the request and sends it to PPDS. HTML files are then
placed into the temp directory, and then the QP replies to the PPES Plug-in with the
encrypted HTML page. The QP is now done and is available for the next incoming
request from the PPES Plug-in.
The PPES Plug-in will then pass the response to the C8 dispatcher via the same
connection that was used for the incoming request. The C8 dispatcher passes the
request back to the load balancer (if it exists). The PPESBusServer connection can
now be used for other incoming and/or waiting requests. The C8 dispatcher receives
the request and parses the response. The HTML page is passed to the CGI, which in
turn passes the request back to the browser.
When using IBM Cognos PowerPlay Client, only the initial open request goes through
the C8 dispatcher and PPESBusServer. All of the subsequent cube requests go
directly to a ppdsweb process via socket communication.
2.3
Comparison with Other Cognos 8 Services
IBM Cognos PowerPlay has different performance characteristics than Report Studio
and Analysis Studio and Query Studio reports. It is not wise to blindly copy the high
and low affinity connection settings from the Report Service to the PowerPlay
Service.
Report Service is typically tuned by adjusting the number of Report Service
processes (Maximum number of processes for the report service during peak
periods) and not adjusting the high and low affinity connection settings. There is no
similar setting for the PowerPlay service because there is only ever one process for
the PowerPlay service.
The PowerPlay service is implemented as a single "dispatcher" child process
(PPESBusServer) that spawns and manages "query processor" child processes
(ppdsweb.exe) that actually service requests. The PowerPlay Service dispatcher
process is lightweight and can easily manage dozens (or more) query processors.
There is no need to ever have more than one dispatcher process. The number of
query processors per PowerCube/package or report is configurable.
Understanding IBM Cognos 8 PowerPlay Performance
7
2.4 Administrative Settings and Migration
When an IBM Cognos Series 7 PowerPlay application is migrated to IBM Cognos
PowerPlay 8, the administrative settings for reports and cubes are migrated. This
can be seen by looking at the PowerPlay tab in IBM Cognos Administration after the
migration has completed, and comparing these settings to the IBM Cognos Series 7
PowerPlay Admin tool.
3 High/Low Affinity Connection Settings
3.1 Understanding the Number of High/Low Affinity Connection Settings
In “IBM Cognos Administration”, click on the “Configuration” tab and then on
“Dispatchers and Services” on the left. The main frame will list the services. Click
on the Properties icon for the PowerPlay service. Then click on the Settings tab.
The settings discussed are the “Number of high affinity connections for the
PowerPlay service during non-peak period” and “Number of low affinity connections
for the PowerPlay service during non-peak period”. These will be referred to as the
number of high and low affinity connections.
Note that these two options should have simply been named “Number of high/low
affinity connections for the PowerPlay service” leaving off the “during non-peak
period.” These settings apply to peak and non-peak periods. In the future, we may
have separate settings for peak and non-peak periods.
The sum of these two settings is the maximum number of concurrent requests that
the PowerPlay Service will allow. In this default case, it’s 1 + 4 = 5.
In addition to affinity settings, maximum processes can be set on a cube and/or
report basis in IBM Cognos Administration, on the PowerPlay tab.
Understanding IBM Cognos 8 PowerPlay Performance
8
Each high and low affinity request causes a new process (ppdsweb or pprp) to be
spawned or an existing process to be re-used. The maximum number of ppdsweb or
pprp processes that are spawned will not exceed the sum of high and low affinity
settings. This needs to be taken into consideration when setting affinity settings. If
you specify 1 and 4 as high and low affinity connections, but allow 10 cube
processes, only 5 processes will ever be spawned.
It’s important to understand the difference between low-affinity and high-affinity
requests.
Low-affinity requests are requests that can be handled equally efficiently by any
PowerPlay server. For example, opening a report can be done equally well by any
one of a number of available servers.
High-affinity requests are requests that can be handled more efficiently by a
PowerPlay server that has handled previous related requests. For example, drilling
down on an already-opened report is a high-affinity request. It makes sense to send
this request back to the same server that initially opened the report to take
advantage of server-side state such as processes that have been started,
connections opened, caches populated. Routing a high-affinity request back to the
same server provides better response time.
High-affinity connections are only used for high-affinity (and absolute affinity)
requests. If there is a low-affinity request (i.e. opening a report) pending, and only
high-affinity connections are available, the low-affinity request will be queued until a
low-affinity connection becomes available.
Understanding IBM Cognos 8 PowerPlay Performance
9
Low-affinity connections can be used for any requests, both high- and low-affinity.
They’re general-purpose. If there are no high-affinity connections available to
service an incoming high-affinity request, it will be processed by a low-affinity
connection. It’s better for a high-affinity operation like “drill” to take a little longer
by using a low-affinity connection than to have it languish in a queue waiting for an
available high-affinity connection.
It may be tempting to set up the system with only low-affinity connections and no
high-affinity connections. By only specifying low-affinity connections, you’re telling
the system to treat all requests equally. If there are no high-affinity connections, a
quick high-affinity request like a drill might wait in a queue behind a bunch of slow
low-affinity open requests. This may result in interactive users (who make highaffinity requests) seeing slower responses than they could. It will also mean that
absolute affinity requests that have to be sent to a particular PowerPlay server may
be queued behind slower low-affinity requests. This will increase the amount of time
it takes for data to appear on the screen and make the user interface appear
sluggish. Having an adequate number of high affinity connections is important.
The default out-of-the-box settings for the high and low affinity connections are
shown in the picture above. The default is one connection for high-affinity requests
and four connections for low-affinity requests, for a total of 5 connections.
3.2
High/Low Affinity Connection Settings and IBM Cognos PowerPlay
Client connections
The High/Low affinity connection settings only apply to IBM Cognos 8 PowerPlay
interactions performed via the portal. IBM Cognos 8 PowerPlay Client can
communicate with local data sources persisted on disk or via remote data sources
persisted on the IBM Cognos 8 environment. While IBM Cognos 8 PowerPlay Studio
communicates to the IBM Cognos 8 PowerPlay service via the IBM Cognos 8
dispatcher, IBM Cognos 8 PowerPlay Client communicates to remote data sources
directly through the IBM Cognos 8 PowerPlay service. Therefore, High/Low affinity
connection settings have no impact on IBM Cognos 8 PowerPlay Client. Remote
requests between the IBM Cognos 8 PowerPlay Client and the IBM Cognos 8
PowerPlay service are light weight in nature and are achieved directly via socket
communications. This contrasts with the heavier requests between IBM Cognos 8
PowerPlay Studio and the IBM Cognos 8 PowerPlay service brokered through the
IBM Cognos 8 dispatcher.
Similar to IBM Cognos Series 7, controlling the overall number of query processors
available to IBM Cognos 8 PowerPlay Client is controlled by the Cube setting for the
minimum and maximum processes on a package by package basis.
3.3
High/Low Affinity Connection Settings Recommendations
Please note that the most important recommendation is to monitor and tune your
system based on the other recommendations!
Understanding IBM Cognos 8 PowerPlay Performance
10
Review administrative settings when deploying to new hardware. If you
are also deploying to new hardware when moving to IBM Cognos 8 PowerPlay, it’s
important to review the administrative settings to see whether they best take
advantage of the new hardware.
Set the total number of connections appropriately. A suggested starting
point is to set the total number of connections based on the number of CPU’s. For a
detailed case study, please see the IBM Cognos 8 PowerPlay Tuning and Best
Practices document.
Monitor and tune the system. This is described in more detail in the Monitoring
and Tuning section. It is vital to monitor and tune the system in order to optimize
performance.
Consider putting Content Manager on a separate machine. In non-trivial
environments (i.e. multi-user environments with significant numbers of packages,
reports), it is generally advised to install Content Manager and the content store on
a separate machine from the PowerPlay server.
4 PowerCube Read Cache
4.1
Understanding PowerCube Read Cache Settings
The default read cache size for published PowerCubes is 80 MB. You can set this
parameter to a value between 1 MB and 1 GB, as required for optimal query
performance.
The optimal read cache size may be higher or lower than the default value of 80 MB.
This is to be expected, as PowerCubes in production vary widely in type and query
characteristics.
Note that the read cache size has no effect on the initial time required to open a
cube.
4.2
Setting PPDS Cache Settings
To change the default PPDS Cache:
1. Open the ppds_cfg.xml (or ppds_cfg.xml.sample).
2. Modify <ReadCacheSize value="80000"/> to what you would like the default
for all data source connections.
To set the PPDS Cache for an existing cube data source:
1. From Cognos Connection, launch IBM Cognos Administration.
Understanding IBM Cognos 8 PowerPlay Performance
11
2.
3.
4.
5.
Click on the Configuration tab.
In your list of data sources, click the data source you would like to modify.
Click ‘Set Properties’ and then click on the Connection tab.
Click Edit the Connection String, and then enter the appropriate value in the
Read Cache Size box.
6. Click OK to close the Edit Connection String dialog box.
4.3
PPDS cache Settings recommendations
The typical profile for query performance, or processing time, follows a pattern
whereby performance increases with the read cache size and then levels off beyond
the optimal setting. To determine the optimal setting, use the resulting query
performance results as a guide for establishing whether reductions or increases are
required.
The optimal read cache size will change as the cube grows and changes in the
production environment. As a result, you should review the optimal read cache size
when changes to the user’s query performance pattern, or changes in the
PowerCube characteristics, occur.
5 Monitoring and Tuning
The goal of the tuning exercise is to set up the system with the smallest number of
processes that fully utilize machine resources.
The best approach is to start with a low number of connections, and increase
gradually, monitoring the system along the way and making adjustments.
Understanding IBM Cognos 8 PowerPlay Performance
12
The Cognos Administrator should watch the queue metrics to determine if the
system is keeping up with demand. To determine if PowerPlay requests are being
queued:
Go to IBM Cognos Administration
Go to the Status tab
Click on System
In the Metrics – System frame, expand the Queue – PowerPlay service entry
Queue length represents the number of items currently in the queue. Time in queue
represents the amount of time queued requests have been waiting to be processed.
If these numbers are high, and the system is not fully utilized, the number of
connections may not be set high enough to meet demand.
The machine administrator should watch the following:




CPU
memory usage
disk IO usage and
swapping
If requests are getting queued and the machine is not maxed out on any of these
criteria, increase the total number of connections. Stop as soon as the machine is
fully utilized on one criterion.
Note that there is a penalty for adjusting the number of connections while the
system is under load. Such adjustments are best done at a non-busy time.
(Performance might be noticeably slow for up to five minutes after the number of
connections is changed.)
If the system is set up with a sub-optimal high/low affinity connection ratio, the
following behaviors will become evident under high load:
 If a system is set up with too high a ratio of high-affinity connections,
opening reports will tend to take too long
 If a system is set up with too high a ratio of low-affinity connections, user
gestures that should be quick, like drill-down, tend to take too long. (What is
happening here is that these requests will be handled by low-affinity
connections in turn. So they may end up queued up after a bunch of report
opens.)
If the total number of connections is set too high, too many concurrent requests will
compete for machine resources resulting in contention for memory and disk, page
faulting, etc. Throughput and performance will suffer. Disk IO rates will go through
the roof and excessive memory and page faulting will be observed.
If the total number of connections is set too low, the machine will not be fully
utilized.
Fly UP