Create a deployment manager and two nodes on two separated machines with Websphere 8.0

Today I want to show an example how I can create a topology of a deployment manager with two nodes created on two separated machines. In the commands below are used the default templates and ports. The summary of steps is:

1) Create the Deployment Manager on machine1
2) Create first Node Agent on machine1
3) Check if profiles have been created
4) Start the Deployment Manager
5) Add first node to Deployment Manager
6) Restart first node and Deployment Manager
7) Create second Node Agent on machine2
8) Add the second node to the Deployment Manager

Details of steps:

(Steps for a fresh environment with no security enabled, the security can be enabled later)

1) Create the Deployment Manager (named Dmgr01) on machine1

<WAS_HOME>/bin/manageprofiles.sh -create -templatePath <WAS_HOME>/profileTemplates/management -portsFile <WAS_HOME>/profileTemplates/management/actions/portsUpdate/dmgr.portdef.props -profileName Dmgr01

2) Create first Node Agent (named Custom01) on machine1

<WAS_HOME>/bin/manageprofiles.sh -create -templatePath <WAS_HOME>/profileTemplates/managed -portsFile <WAS_HOME>/profileTemplates/managed/actions/portsUpdate/portdef.props -profileName Custom01

3) Check if profiles Dmgr01 and Custom01 are present:

<WAS_HOME>/bin/manageprofiles.sh -listProfiles

4) Start the Deployment Manager:

<WAS_HOME>/profiles/Dmgr01/bin/startManager.sh

5) Add first node to Deployment Manager:

<WAS_HOME>/bin/addNode.sh hostname1 8879 -profileName  Custom01

6) Restart first node and Deployment Manager:

<WAS_HOME>/profiles/Custom01/bin/stopNode.sh
<WAS_HOME>/profiles/Dmgr01/bin/stopManager.sh
<WAS_HOME>/profiles/Dmgr01/bin/startManager.sh
<WAS_HOME>/profiles/Custom01/bin/startNode.sh

7) Creating second Node Agent on machine2 with specific node name:

<WAS_HOME>/bin/manageprofiles.sh -create -templatePath <WAS_HOME>/profileTemplates/managed -portsFile <WAS_HOME>/profileTemplates/managed/actions/portsUpdate/portdef.props -profileName Custom02 -nodeName hostname2Node02

8) Add the second node to the Deployment Manager (of the first machine1):

<WAS_HOME>/bin/addNode.sh hostname1 8879 -profileName Custom02


This is a screenshot of the nodes created:

Official docs:
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.migration.nd.doc/info/ae/ae/rxml_manageprofiles.html?resultof=%22%6d%61%6e%61%67%65%70%72%6f%66%69%6c%65%73%2e%73%68%22%20

Scaling adding agents with IBM Rational Performance Tester

To scale with more users means, generally talking, increasing the parallelization and this can be done with clustering, adding new servers to divide the workload,  adding more agents, etc. 

When this is not possible to do then the alternative could be to increase the resources, but not always can be the solution to scale, depends on the applications and systems.

Instead scaling with IBM Rational Performance Tester (alias RPT, a product to simulate the load of many users that execute parallel requests to the servers) means run the RPT scripts increasing the number of virtual user that run them. At a certain point the number of virtual users can be increased adding new additional RPT agents.  

I show here the summarized steps how to do:

1) install the RPT agents. The number of agents depends on different variables:

- how much expensive is the execution of scripts
- how much users you need to scale up
- hardware and software performances of the RPT machines.

In this example the agents are installed on Windows platform.

2) define the related agents on the RPT workbench. For example these below:

agent1
agent2
agent3
agent4

3) assign these properties to each agent:

ROOTDIR=c:\RationalAgent
OPERATING_SYSTEM=WINDOWS
RPT_ENABLE_IP_ALIASING=FALSE
RPT_IPA_ENABLE_ALL_INTERFACES=TRUE
RPT_DEFAULT_MEMORY_SIZE=1500
RPT_VMARGS = 
-Xms1500m -Xgcpolicy:gencon -DKEEP_ALIVE_ACROSS_TEST=TRUE

Like in the screenshot below:

Note: RPT_DEFAULT_MEMORY_SIZEis overriden by the value -Xms1500m defined in of RPT_VMARGS  4) On each agent Windows machine, edit the registry under HKEY_LOCAL_MACHINE > System > CurrentControlSet > Services > TCPIP > Parameters, adding the following parameters below. All the parameters have to be added as a DWORD and the values set as Decimal:

MaxUserPort                 65534
TcpTimedWaitDelay            30
MaxFreeTcbs                 72000
MaxHashTableSize            65535
TcpWindowSize               65535
EnableDynamicBacklog        1
MinimumDynamicBacklog       20
MaximumDynamicBacklog       1000
DynamicBacklogGrowthDelta 10
TcpAckFrequency             1 


5) At this point with a RPT schedule you can distribute the execution of the RPT scripts among all different RPT agents. 

In this example below the schedule has 4 scripts equally distributed on all agents with a stage allocating 400 users that enter one each 2 seconds and run the scripts for 60 minutes. In total the test takes (2x400) seconds + 60 minutes to complete.

This screenshot shows that test1 runs on agents1:





Note: please refer to official IBM documentation:

http://pic.dhe.ibm.com/infocenter/rpthelp/v8r2m0/index.jsp?topic=%2Fcom.ibm.rational.test.lt.doc%2Ftopics%2Fc_perftips.html

http://www.ibm.com/developerworks/rational/library/optimize-load-handling/index.html

How to look for db2 connections leak?

During the execution of a scalability and performance test the db2 connections tipically increase, because more clients are performing requests to the database and are increasing the load. But after you finish the test, you would like to verify that database connections start decreasing as number because not they are not more needed and they should go close to the number of the start.

An exception to this reasoning is when the clients are connecting with a connection pool that keeps always a minimun number of connections always open to avoid  wasting time opening and closing them. Then in this case even if you completed the tests, do not get you surprised when you return back the morning later and see that the number of connections opened are the same like the night before. This is right when this number is the same like the minimum connections number defined on the connection pool.

Check with these few rows to run in a shell:

su - db2instance_user

while (true) do

timenow=$(date +'%Y%m%d-%H%M%S'); 
connections=$(db2 list applications for db yourdb show detail | grep "string to match" | wc -l);
echo $timenow, $connections
sleep 60
done


"string to match", can be db2jcc_application or the ip address of the server where is running the application that perform the requests.

If the number of connections displayed do not  decrease and remains alive without any reason there are some potential connection leak. Else investigate if on the client there is still actually some activity.