...

IBM Cognos 8 PowerPlay Tuning and Proven Practices

by user

on
Category: Documents
2

views

Report

Comments

Transcript

IBM Cognos 8 PowerPlay Tuning and Proven Practices
IBM Cognos 8 PowerPlay
Tuning and Proven Practices
Nature of Document: Proven Practice
Product(s): IBM Cognos 8 PowerPlay
Area of Interest: Performance
IBM Cognos 8 PowerPlay Tuning and Best Practices
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]
Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks
or trademarks of Adobe Systems Incorporated in the United States, and/or other countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in
the United States, other countries, or both .
IBM Cognos 8 PowerPlay Tuning and Best Practices
Table of Contents
1
Introduction..................................................................................................................... 4
1.1
1.2
1.3
Purpose...................................................................................................................... 4
Applicability................................................................................................................. 4
Exclusions and Exceptions......................................................................................... 4
Tuning and Best Practices.............................................................................................. 4
2.1
2.2
2.3
3
Determining the Number of High and Low Affinity Threads Required........................ 4
Determining the Most Suitable Read Cache Size...................................................... 6
Determining the Location of the PowerCube.............................................................. 8
Determining a Basic Sizing Model for IBM Cognos 8 PowerPlay................................. 10
4
IBM Cognos 8 PowerPlay Scalability............................................................................ 11
2
4.1
Horizontal Scalability (Add an additional Application server but keep users constant)
11
4.2
Vertical Scalability (Add an additional Application server and double users)........... 12
5
IBM Cognos 8 PowerPlay and IBM Cognos 8 Interoperability...................................... 13
6
Conclusion.................................................................................................................... 15
7
Appendix A: Scalability Environment Overview............................................................ 16
8
Appendix B: Operating System Tuning Parameters..................................................... 17
PowerPlay 8 Tuning and Best Practices
1
Introduction
1.1 Purpose
This document provides various tuning suggestions and guidelines IBM Cognos 8 PowerPlay such that
customers are able to obtain optimal performance in their current environment. This document also
outlines a basic sizing model for IBM Cognos 8 PowerPlay along with how response times can improve
if additional hardware is added into the environment. Lastly, this document also covers how IBM
Cognos 8 PowerPlay can be integrated into an existing IBM Cognos 8 environment and vice-versa.
For specific information on the environment used and types of reports used, please refer to Appendix
A: Scalability Environment Overview.
1.2 Applicability
This document is applicable to the IBM Cognos 8 PowerPlay 8.4 release. The information contained in
this document was validated using:
● IBM Cognos 8 PowerPlay 8.4.27.27
1.3 Exclusions and Exceptions
The information contained in this document may evolve over time. It is important to note that all
information in this document pertain strictly to the IBM Cognos 8 PowerPlay 8.4 release.
2
Tuning and Best Practices
This section illustrates various methods of tuning an existing IBM Cognos 8 PowerPlay environment.
These methods include determining the number of High and Low Affinity threads required in order to
service a user community of a given size; determining a suitable Read Cache Size, and finally,
deciding on the location of the Power Cube. Each server used in our test environment, referenced in
Appendix A: Scalability Environment Overview, was tuned at the Operating System Level according to
the recommendations referenced in Appendix B: Operating System Tuning Parameters.
2.1 Determining the Number of High and Low Affinity Threads Required
There are several factors we must consider when determining how many High and Low Affinity
Threads we need to service a given user community. They are:
 How much Physical Memory (RAM) is available on the server?
 What is the maximum number of users which may be using the system at any given time?
 We must allocate a sufficient number of threads such that we can service the requests of all users
without any connections timing out.
 The number of Threads we choose must not negatively impact performance.
PowerPlay 8 Tuning and Best Practices
Methodology:
 100 simultaneous users with no rest time between actions.
 Run with our typical threading model {16 Threads and 20 processes}.
 Run with Threads = 1/3 x number of Users {100 x 1/3 = ~30Threads (30 processes)}
 Run with Threads = 1/2 x number of Users {100 x 1/2 = ~50Threads (50 processes)}
 Keep all other variables constant such as Read Cache Size and Cube Location
 Measure response times, transaction pass rate and resource consumption.
 Caveat 1. The number of threads and processes we set must not consume more Physical Memory
than is available on the server.
Observations:
Using Threads = 1/3 x Number of Users proves to be our best threading model as it produced
the best response times and best pass rate with no significant resource utilisation when compared to
the default configuration. Using Threads = 1/2 x Number of Users causes an increase in Virtual
Memory.
So, if our Number of Users = 100, we will require approximately 30 threads. For the purposes of our
example, we used 8 High Affinity Threads, 22 Low Affinity Threads, and a maximum of 30 ppdsweb
processes (query processors). The following diagram illustrates that no negative performance impact
is observed when using the Threads = 1/3 x Number of Users Threading Model:
Determining the best Threading Model (Configuration #9 and Configuration #10 Vs. Default Threading Model (Configuration #6))
800.00
Average Transaction Time (s)
700.00
722.25
743.19
719.63
Default threading Model (Configuration
#6)
600.00
Threads = 1/2 x Number of Users
(Configuration #9)
500.00
400.00
Configuration #6
Configuration #9
Configuration #10
Threads = 1/3 x Number of Users
(Configuration #10)
300.00
200.00
100.00
0.00
100
Simultaneous Users
Configuration Details:
Default Threading Model (Configuration #6): 4 High Affinity Threads, 16 Low Affinity Threads,
Maximum of 24 Processes
Threads = 1/2 x Number of Users (Configuration #9): 8 High Affinity Threads, 42 Low Affinity
Threads, Maximum of 50 Processes (100 users)
PowerPlay 8 Tuning and Best Practices
Threads = 1/3 x Number of Users (Configuration #10): 8 High Affinity Threads, 22 Low Affinity
Threads, Maximum of 30 Processes (100 users)
Conclusion:
Using the Threads = 1/3 x Number of Users Threading Model, we’re able to maintain optimal
performance without consuming additional resources. Also, it allows all 100 users to run requests
simultaneously without encountering any connection time outs. Using a larger threading model, such
as “Threads = 1/2 x Number of Users” resulted in the consumption of additional Virtual Memory
without obtaining better performance.
2.2 Determining the Most Suitable Read Cache Size
Methodology:
 Using our best Threading Model “Threads = 1/3 x Number of Users” and holding all other
variables constant, change the Read Cache Size from 80 MB (Default) to 256 MB and 512 MB.
Examine how performance is affected.
 It must not negatively impact performance.
 We must not consume more Physical Memory than is available on the server.
Observations:
Adjusting the Read Cache Size improved performance up to 17%. By default, the Read Cache Size is
set to 80 MB for the Data Source connection to the Power Cube. Using an even larger Read Cache
(i.e. 512 MB) did not result in the same performance gain as noted when using a 256 MB cache.
Please note that the size of the cube used in our tests was 225 MB. Also, the reports that were used
execute a long running query. Please note that only the Read Cache Size was adjusted in this
example. All other variables remain constant. The following diagram illustrates the performance gain
observed when using a 256 MB cache:
Dete rming the most suitable Cache Size (Configuration #11 and Configuration #12 Vs. De fault Cache Size
(Configuration #10))
17.4 % Gain
Average Transaction Time (s)
800.00
700.00
719.63
600.00
594.65
621.96
Configuration #11
Configuration #12
500.00
400.00
Configuration #10
Default Cache - Configuration #10
256 MB Cache - (Configuration #11)
300.00
512 MB Cache - (Configuration #12)
200.00
100.00
0.00
100
Simultaneous Users
PowerPlay 8 Tuning and Best Practices
Configuration Details:
Default Cache (Configuration #10): Threads = 1/3 x Number of Users: 8 High Affinity Threads, 22
Low Affinity Threads, Maximum of 30 Processes (100 users), 80 MB Read Cache.
256 MB Read Cache (Configuration #11): Threads = 1/3 x Number of Users: 8 High Affinity Threads,
22 Low Affinity Threads, Maximum of 30 Processes (100 users), 256 MB Cache
512 MB Read Cache (Configuration #12): Threads = 1/3 x Number of Users: 8 High Affinity Threads,
22 Low Affinity Threads, Maximum of 30 Processes (100 users), 512 MB Cache
On average, each ppdsweb appears to use 76% more Virtual Memory when using a 256 MB Cache
compared to using the default cache size of 80 MB. Since we’re using a maximum of 30 processes (in
our test) and the average virtual size of each ppdsweb is about 561 MB, 30 x 561 MB = 16.8 GB. If
we take Java into consideration (in which its average size is 1.4 GB) and the PPESBusServer (which is
226 MB), Total VM Usage = 16.8 GB + 1.4 GB + 226 MB (or ~18.4 GB). Given that our server has 32
GB of RAM, we are well within our limits using Configuration #11 (with a 256 MB cache).
Average Size of all Processes for Determining the most suitable Cache Size at 100 users
1600000
1400000
Average Size (in KB)
1200000
1000000
Configuration #6 - Default Cache (80 MB)
76 % Difference
800000
Configuration #11 - 256 MB Cache
Configuration #12 - 512 MB Cache
600000
400000
200000
y
2s
ys
tra
db
2s
ys
cs
db
eb
pp
ds
w
er
PP
ES
Bu
sS
er
v
)
(P
PE
S
Ja
va
)
W
(G
a
Ja
v
Ja
v
a
(C
M
)
0
Process Name
Configuration Details:
Default Cache (Configuration #10): Threads = 1/3 x Number of Users: 8 High Affinity Threads, 22
Low Affinity Threads, Maximum of 30 Processes (100 users), 80 MB Read Cache.
256 MB Read Cache (Configuration #11): Threads = 1/3 x Number of Users: 8 High Affinity Threads,
22 Low Affinity Threads, Maximum of 30 Processes (100 users), 256 MB Cache
512 MB Read Cache (Configuration #12): Threads = 1/3 x Number of Users: 8 High Affinity Threads,
22 Low Affinity Threads, Maximum of 30 Processes (100 users), 512 MB Cache
PowerPlay 8 Tuning and Best Practices
Conclusion:
Although changing the Read Cache Size from 80 MB (Default) to 256 MB in our case improved
performance by 17%, this may vary depending on the size of the PowerCube used along with the
types of reports used (if they are long running or short running reports for example). It may be
necessary to further experiment with this setting in order to obtain best performance.
2.3 Determining the Location of the PowerCube
Methodology:
 Move the PowerCube from the Content Manager to the PowerPlay 8 Server. Examine how
changing the location of the cube impacts performance. Keep the number of threads constant
along with the cache size.
 Changing the cube location must not negatively impact performance.
Observations:
Storing the PowerCube locally on the IBM Cognos 8 PowerPlay server resulted in a performance gain
of up to 35% in comparison to storing it on a remote server (or on the Content Manager in our
example). Another advantage to using this configuration is that no additional Virtual Memory is
consumed. Please note that only the location of the PowerCube was changed in this example. All
other variables remain constant. The diagram below illustrates the performance gain observed after
moving the cube from IBM Cognos 8 content Manager to the IBM Cognos 8 PowerPlay server.
Determining the Impact of changing the Cube Location from CM to the PP8 Server (Configuration #1 and
Configuration #6) (At 100 users)
1300.00
Average Transaction Time (s)
1200.00
1100.00
35% Gain
1106.80
1000.00
900.00
722.25
800.00
700.00
Configuration #6 - Cube on PP8 Server
600.00
500.00
Configuration #1 - Cube on CM
Configuration
Configuration
400.00
300.00
200.00
100.00
0.00
100
Simultaneous Users
PowerPlay 8 Tuning and Best Practices
Configuration Details:
Cube on the IBM Cognos 8 Content Manager server: Configuration #1: 4 High Affinity Threads, 16
Low Affinity Threads, Maximum of 24 Processes, 80 MB Read Cache, Cube on IBM Cognos 8 Content
Manager
Cube on PP8 Server: Configuration #6: 4 High Affinity Threads, 16 Low Affinity Threads, Maximum of
24 Processes, 80 MB Read Cache, Cube on IBM Cognos 8 PowerPlay server.
Conclusion:
It’s highly recommended that the PowerCube is placed on the IBM Cognos 8 PowerPlay server as
opposed to on a remote server.
It’s important to note that when setting up the Data Source
Connection to the PowerCube, the cube must be located at the exact same location on all servers
since this is a shared configuration setting. For example, if your cube is located in E:\Cubes on one
IBM Cognos 8 PowerPlay server, it must also reside in E:\Cubes if any additional IBM Cogno 8
PowerPlay servers are added into the environment.
2.4 Summary
Combining all three of the suggestions mentioned in Sections: 2.1, 2.2. and 2.3 (i.e. Using a
combination of High and Low Affinity Threads equal to 1/3 x the Number of Users; adjusting the Read
Cache Size beyond 80 MB; and placing the PowerCube on the PowerPlay 8 server) results in the most
significant performance gain (up to 46%). Included below is a table summarizing our findings based
on the various tuning methods:
Tuning Method
Using our optimal threading model (Threads = 1/3 x Number of Users)
Using a 256 MB Read Cache
Moving the cube from CM to the PP8 Server
Using Threads = 1/3 x Number of users, 256 MB Read Cache, and
moving cube from CM to PP8 Server
Overall Performance
Gain (in %)
0.36%
17.37%
34.74%
46.20%
PowerPlay 8 Tuning and Best Practices
3
Determining a Basic Sizing Model for IBM Cognos 8
PowerPlay
Included below are several suggestions offered to assist in determining the requirements of a IBM
Cognos 8 PowerPlay server prior to deploying the product in a given environment. The following
steps may be used to assist in determining how much Physical Memory is required for the server:







Estimate the maximum number of users. Base this on your estimated peak load.
Determine a set of reports to use in your estimate (typically the heaviest reports).
Determine the approximate optimal read cache size. Using the set of reports, run them with
the default 80MB cache as a baseline. Try two or three increased read cache settings to
determine best response time. Select the Read Cache Size which results in the best response
time.
Setup IBM Cognos 8 PowerPlay in a simple single server environment, and run the set of
reports (consisting of the longest running reports) using the best read cache size to determine
the average size of the ppdsweb process. Also, determine the average size of the
PPESBusServer.
If the maximum number of users for example is 100, we would use our most suitable
threading model (Threads = 1/3 x Number of Users) to determine roughly how many
connections we will need (In this case, Number of Threads would equal approximately 30).
We could select 8 High Affinity Threads, 22 Low Affinity Threads, and a total of 30 processes
as an example.
Assuming the Average Virtual Size of our ppdsweb process is 500 MB, we would need about
30 x 500 MB or 15 GB. The maximum size Java may reach is 2 GB in a 32-bit environment
(worst case situation). Assume our PPESBusServer may average 220 MB in size. This would
imply that we would need approximately (30 x 500 MB for each ppdsweb) + 2 GB (for Java) +
250 MB (for PPESBusServer) or approximately 17 GB of RAM on our Server.
From our findings, using a 256 MB Read Cache improved performance, however, it may be
necessary to adjust this further depending on the size of your cube.
PowerPlay 8 Tuning and Best Practices
Memory Sizing Model
The following table summarizes how our Memory Sizing Model can be used to determine the
requirements of an IBM Cognos 8 PowerPlay server:
Prerequisites
 Determine the Maximum Number of Users.
 Adjust the Read Cache Size beyond 80 MB (Default) and run a selection of the longest
running reports as a sample to determine if there’s any notable performance
improvement. It may be necessary to test several different Read Cache Sizes in order
to identify the most suitable one. Select the most suitable cache size.
 Run each of the long running reports individually (using the most suitable Read Cache
Size) to determine the average size of the ppdsweb (Query Processor).
 Determine the average size of the PPESBusServer.
 Assume the maximum Virtual Size of Java to be 2 GB.
Determine Physical Memory Required:
** Using the information obtained above, the following calculation can be used to determine
how much RAM is required on the server:
Required RAM = ((1/3 x Number of Users) x Average Size of each ppdsweb) + Average Size of
PPESBusServer + 2 GB (for Java)
Please note that 1/3 x Number of Users in our calculation represents our Threading model.
Caveat: Since IBM Cognos 8 PowerPlay is CPU bound, it’s very difficult to clearly identify the
optimal configuration on a user / (per) CPU basis. If no significant performance improvements are
noted by performing the above recommendations, and it’s observed that many of the ppdsweb
(query) processes appear idle at peak load, it may be necessary to increase the processing
capacity of the server. This would require additional investigation before coming to a conclusion
however since its dependant on a variety of factors.
4
IBM Cognos 8 PowerPlay Scalability
4.1 Horizontal Scalability (Add an additional Application server but keep users
constant)
In theory, if a second IBM Cognos 8 PowerPlay server is added into an existing environment, it’s
expected that the transaction response times become twice as fast with a constant user load after
adding a second application server into the environment.
PowerPlay 8 Tuning and Best Practices
As an example, we’ve taken our best configuration (using a threading model of Threads = 1/3 x
Number of users, a 256 MB Read Cache, along with the cube residing on the IBM Cognos 8 PowerPlay
server) to examine this behaviour.
Based on our results, if we keep the user load constant (at 50 and 100 users) and add an additional
IBM Cognos 8 PowerPlay server into our environment, the response times do become twice as fast in
comparison to using a single IBM Cognos 8 PowerPlay server.
Horizontal Scalability for Configuration #11 (at the 50 and 100 user data points)
Total Average Time (s)
700.00
594.653
600.00
500.00
51% Difference
400.00
300.00
200.00
100.00
288.87
50% Difference
317.26
One
157.86
One
Server
One Server
Two Servers
Two Servers
Two Servers
0.00
50
100
Number of Users
IBM Cognos 8 PowerPlay Configuration: Threads = 1/3 x Number of Users: 8 High Affinity Threads,
22 Low Affinity Threads, Maximum of 30 Processes (100 users), 256 MB Cache, Cube on each IBM
Cognos 8 PowerPlay server.
4.2 Vertical Scalability (Add an additional Application server and double users)
Similarly, if we double the user load and add an additional IBM Cognos 8 PowerPlay server into our
environment, we can see that the transaction response times remain constant:
Vertical Scalability for Configuration #11 at 50 users (effect of adding an additional Server and
doubling load)
Total Average Time (s)
350.00
317.26
300.00
9% Difference
288.87
250.00
200.00
150.00
One
Two Servers
One Server
Two Servers
100.00
50.00
0.00
50
100
Number of Users
PowerPlay 8 Configuration: Threads = 1/3 x Number of Users: 8 High Affinity Threads, 22 Low Affinity
Threads, Maximum of 30 Processes (100 users), 256 MB Cache, Cube on IBM Cognos 8 PowerPlay
server.
PowerPlay 8 Tuning and Best Practices
Conclusion:
Based on the results of this test IBM Cognos 8 PowerPlay demonstrates solid vertical and horizontal
scalability characteristics. Thus adding a secondary IBM Cognos 8 PowerPlay server into an
environment should significantly improve performance. This may be necessary if the existing
environment is constrained by the amount available physical memory on the IBM Cognos 8 PowerPlay
server at the maximum user load, or if CPU contention is noted.
PowerPlay 8 Tuning and Best Practices
5
IBM Cognos 8 PowerPlay and IBM Cognos 8
Interoperability
In some cases, it may be necessary to integrate IBM Cognos 8 PowerPlay into an existing IBM Cognos
8 environment or vice-versa. We must ensure that the response times of the IBM Cognos 8
PowerPlay transactions don’t degrade as we add IBMCognos 8 users into the environment. Also, the
response times of the IBM Cognos 8 transactions must not degrade as we add IBM Cognos 8
PowerPlay users.
Methodology:
 100 simultaneous users (no think times) in proportions of (80/20, 50/50, and 20/80) distributions
(IBM Cognos 8 PowerPlay to IBM Cognos 8 users).
 Both IBM Cognos 8 PowerPlay and IBM Cognos 8 reside on separate servers.
 Run with Threads = 1/3 x number of Users {100 x 1/3 = ~30Threads (30 processes)}
 Run with 16 x BIBusTKServerMain.
 Run with optimal Read Cache Size of 256 MB.
 Cube is located locally on the IBM Cognos 8 PowerPlay server.
 We must not exhaust the amount of physical memory available on the server.
 The IBM Cognos 8 PowerPlay transactions must not degrade as we add IBM Cognos 8 users.
Similarily, the IBM Cognos 8 transactions must not degrade as we add IBM Cognos 8 PowerPlay
users.
Observations:
IBM Cognos 8 PowerPlay and IBM Cognos 8 performed best when installed on separate servers. Also,
there was no resource contention on either server. As we scale up in IBM Cognos 8 PowerPlay users
and scale down in IBM Cognos 8 users the transaction response times of the IBM Cognos 8 PowerPlay
users increase proportionally to the number of IBM Cognos 8 PowerPlay users we add:
Total Response Time (Seconds)
Comparison of 100 PP8 users to the PP8 Response Times of the 80/20, 50/50, and 20/80 user
distributions at the 100 user data point (Two Servers)
700.00
600.00
594.65
498.38
500.00
PP8 Baseline
80/20 distribution
400.00
321.10
300.00
200.00
PP8 Baseline
80/20
distribution
50/50 distribution
20/80 distribution
50/50
100.00
135.00
20/80
0.00
100
Number of Users
PowerPlay 8 Tuning and Best Practices
IBM Cognos 8 PowerPlay Configuration: Threads = 1/3 x Number of Users: 8 High Affinity Threads,
22 Low Affinity Threads, Maximum of 30 Processes (100 users), 256 MB Cache, Cube on PP8 Server.
IBM Cognos 8 Configuration: 16 x BiBusTKServerMain.
Similarly, as we scale up in IBM Cognos 8 users and scale down in IBM Cognos 8 PowerPlay users,
the transaction response times of the IBM Cognos 8 users increase proportionally to the number of
IBM Cognos 8 users we add:
Total Response Time (Seconds)
Comparison of 100 C8 users to the C8 Response Times of the 80/20, 50/50, and 20/80 user distributions
at the 100 user data point (Two Servers)
60.00
50.00
50.01
34.51
40.00
C8 Baseline
80/20 distribution
30.00
20.00
10.00
0.00
50/50 distribution
20/80 distribution
21.47
C8 Baseline
13.36
50/50
80/20
distribution
20/80
100
Number of Users
IBM Cognos 8 PowerPlayConfiguration: Threads = 1/3 x Number of Users: 8 High Affinity Threads, 22
Low Affinity Threads, Maximum of 30 Processes (100 users), 256 MB Cache, Cube on IBM Cognos 8
PowerPlay server.
IBM Cognos 8 Configuration: 16 x BiBusTKServerMain
Conclusion:
When IBM Cognos 8 PowerPlay and IBM Cognos 8 are installed on separate servers, the response
times of the IBM Cognos 8 PowerPlay users are not affected by introducing IBM Cognos 8 users.
Similarly, the response times of the IBM Cognos 8 users are not affected by introducing IBM Cognos 8
PowerPlay users. It’s recommended that both IBM Cognos 8 PowerPlay and IBM Cognos 8 reside on
separate servers, especially if system resources are an issue.
Please keep in mind here that it’s necessary to closely monitor the Gateway and Content Manager to
ensure that there is no resource contention.
PowerPlay 8 Tuning and Best Practices
6
Conclusion
Using a “Threads = 1/3 x Number of Users” threading model along with a 256 MB Read Cache (with
the cube located on the IBM Cognos 8 PowerPlay server) resulted in a performance gain of up to
46%. It’s important to note here that these performance gains may vary depending on the size of
the PowerCube and reports used. Therefore, it may be necessary to tune beyond the
recommendations listed in this article. If it appears that there is a constraint with the amount of
available physical memory along with CPU, it may be necessary to add an additional IBM Cognos 8
PowerPlay server into the environment. If PowerPlay 8 is being integrated into an existing IBM
Cognos 8 environment, it’s recommended that both IBM Cognos 8 PowerPlay and IBM Cognos 8
reside on separate servers.
PowerPlay 8 Tuning and Best Practices
7
Appendix A: Scalability Environment Overview
The following environment consisting of one Gateway, two IBM Cognos 8 PowerPlay /IBM Cognos 8
application servers, and one Content Manager was used for the purposes of these tests. Please refer
to the following topology diagram for a high level overview of the environment:
Load Runner
Controller
LDAP
Gateway
Cognos 8/PowerPlay8
Server
Cognos 8/PowerPlay8
Server
Content Manager
Reporting Database
Content Store
Figure 1. IBM Cognos 8 PowerPlay /IBM Cognos 8 Multi-Server Scalability Environment
Important Note: The reports that were used to conduct this investigation were developed by an
authored expert. These reports were designed to exercise “long running queries” in which the IBM
Cognos 8 PowerPlay server is heavily loaded.
PowerPlay 8 Tuning and Best Practices
8
Appendix B: Operating System Tuning Parameters
It has been proven from previous IBM Cognos 8 BI Engagements that setting the TcpTimedWaitDelay
and MaxUserPort paramters in the Windows Registry is a necessity in order to scale to reasonable
user loads. TcpTimedWait delay controls the amount of time that must elapse before TCP/IP can
release a connection and re-use its resources. MaxUserPort defines the highest port number TCP/IP
can assign. For the purposes of our tests these parameters were set as follows:
TcpTimedWaitDelay = 0x 0000001e (30) (Type: DWord)
MaxUserPort = 0x0000fffe (65534) (Type: DWord)
These keys must be present in the following registry location on each server in the environment:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters
Fly UP