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 cscogpp@ca.ibm.com. 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 1.1 1.2 1.3 2 2.1 2.2 2.3 3 4 4.1 Introduction..................................................................................................................... 4 Purpose...................................................................................................................... 4 Applicability................................................................................................................. 4 Exclusions and Exceptions......................................................................................... 4 Tuning and Best Practices.............................................................................................. 4 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 IBM Cognos 8 PowerPlay Scalability............................................................................ 11

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 7 8 Conclusion.................................................................................................................... 15 Appendix A: Scalability Environment Overview............................................................ 16 Appendix B: Operating System Tuning Parameters..................................................... 17

PowerPlay 8 Tuning and Best Practices

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.

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 700.00 Average Transaction Time (s) 600.00 500.00 400.00 300.00 200.00 100.00 0.00 100 Simultaneous Users Configuration #6 Configuration #9 Configuration #10 Threads = 1/2 x Number of Users (Configuration #9) Threads = 1/3 x Number of Users (Configuration #10) 722.25

743.19

719.63 Default threading Model (Configuration #6)

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, were 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
800.00 Average Transaction Time (s) 700.00 600.00 500.00 400.00 300.00 200.00 100.00 0.00 100 Simultaneous Users Configuration #10 Configuration #11 Configuration #12 719.63 594.65 621.96

Default Cache - Configuration #10 256 MB Cache - (Configuration #11) 512 MB Cache - (Configuration #12)

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 were 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 1200000 Average Size (in KB) 1000000 76 % Difference 800000 600000 400000 200000 0
2s ys cs ) (C M eb er ) ) Bu sS er v 2s ys tra (P PE S W ds w (G y

Configuration #6 - Default Cache (80 MB) Configuration #11 - 256 MB Cache Configuration #12 - 512 MB Cache

Ja v

Ja v

Ja va

pp

db

PP ES

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

db

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 1200.00 Average Transaction Time (s) 1100.00 1000.00 900.00 800.00 700.00 600.00 500.00 400.00 300.00 200.00 100.00 0.00 100 Simultaneous Users Configuration Configuration 722.25 Configuration #1 - Cube on CM Configuration #6 - Cube on PP8 Server 1106.80 35% Gain

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: Its highly recommended that the PowerCube is placed on the IBM Cognos 8 PowerPlay server as opposed to on a remote server. Its 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

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 theres 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, its 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 its 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.

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, its 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, weve 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) 700.00 Total Average Time (s) 600.00 500.00 400.00 300.00 200.00 100.00 0.00 50 Number of Users 100 317.26 51% Difference 50% Difference 157.86 One Server Two Servers One Two Servers 288.87 One Server Two Servers 594.653

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) 350.00 Total Average Time (s) 300.00 250.00 200.00 150.00 100.00 50.00 0.00 50 Number of Users 100 One Two Servers One Server Two Servers 317.26 9% Difference 288.87

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

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 dont 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:
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)
Total Response Time (Seconds)

700.00 600.00 500.00 400.00 300.00 200.00 100.00 0.00 100

Number of Users

594.65 498.38
PP8 Baseline 80/20 distribution

321.10 PP8 Baseline 80/20 distribution 50/50 135.00 20/80

50/50 distribution 20/80 distribution

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:

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) Total Response Time (Seconds) 60.00 50.00 40.00 30.00 20.00 10.00 0.00 21.47 C8 Baseline 13.36 80/20 distribution 100 Number of Users 50/50 20/80 50.01 34.51
C8 Baseline 80/20 distribution 50/50 distribution 20/80 distribution

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. Its 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 its necessary to closely monitor the Gateway and Content Manager to ensure that there is no resource contention.

PowerPlay 8 Tuning and Best Practices

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%. Its 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, its recommended that both IBM Cognos 8 PowerPlay and IBM Cognos 8 reside on separate servers.

PowerPlay 8 Tuning and Best Practices

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

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