Using Test Load Generator

This chapter contains the following topics:

•

Overview

•	Creating Call Path Policy for a Replay

•	Creating a Replay Definition

•	Running a Replay

•	Running a Replay in Auto-Created Test Domain

Overview

Test load generator is a Tuxedo applications load test tool that facilitates effective and efficient load testing. This feature works in conjunction with the payload collection feature to capture the call path and payload metrics coming from a domain gateway, Web service client or application server. One can create replay definition from call paths and execute the replay based on policies for standard and stress test modes.

 

Creating Call Path Policy for a Replay

A replay can be constructed from one or more call paths.

In order to collect call path and payload metrics, you need to create a call path policy on the target service with payload collection enabled by doing these steps:

1.	From the TSAM Plus console top menu bar, click Policy-> Tuxedo Monitoring Policy.

2.	In the Monitoring Policy List page, click Add to enter the Create Policy page.

3.	In the Call path tab, select Enable to enable the call path metrics collection.

4.	Select the domain in which payload data will be collected in the left Domain list, the Define Payload Collection button is activated. Click the button.

5.	In the Define Payload Collection page, enable request and response payload collection by selecting the corresponding checkbox.

It is recommended you select Initial Called Service Only to avoid collecting unnecessary metrics. The payload collection must not include any result filter.

Creating a Replay Definition

After the call path policy for the replay is created, do one or more Tuxedo calls to collect the source metrics from call paths. Then you can create a replay definition from call paths by doing these steps:

1.	From the TSAM Plus console top menu bar, click Load Generator-> Replay Definition.

2.	Click Add. The Call Path Query and Call Path Result Panels are displayed.

3.	Set the query filter options and click Query. The desired call paths are displayed in the result panel.

4.	Select the call path from the list and click Create Replay Definition.

The new-created replay definition is displayed in the Replay Definition list.

Setting Replay Definition Attributes

You can edit the replay definition attributes.

Table 8‑1 lists replay definition attributes.

 

Table 8‑1 Replay Definition Attributes

Attribute	Description	Default Value	Editable
name	Replay definition name		yes
Tuxedo user name	The Tuxedo user name used to do tpinit()		yes
Tuxedo client name	The Tuxedo client name used to do tpinit()		yes
Tuxedo group name	The Tuxedo client name used to do tpinit()		yes
transaction calls	Call tpbegin() when starting the call(s), and call tpcommit() when ending the calls	From source call path metrics	yes
transaction parameters	Call tpbegin() when starting the call(s), and call tpcommit() when ending the calls	From source XA metrics	no
break when any call fails	Whether to break when any call fails. Its value is yes or no.		yes
create time	The time when the definition was created		no
modify time	The time when the definition was modified		no

The default service call attributes are from the first called service (not the "Initial Called Service" in the call path when the initiator is a server) when the replay definition is constructed from call path metrics. Table 8‑2 lists service calls attributes of replay definition.

 

Table 8‑2 Replay Definition Service Calls Attributes

Attribute	Default Value	Editable
service name	From source metrics	No
source correlation ID	From source metrics	No
call flag "TPNOTRAN"	From the source metrics	Yes
call flag "TPNOCHANGE"	From the source metrics	Yes
call flag "TPNOCOPY"	From the source metrics	Yes
call flag "TPNOBLOCK"	From the source metrics	Yes
call flag "TPNOTIME"	From the source metrics	Yes
call flag "TPSIGRSTRT"	From the source metrics	Yes

Running a Replay

To run a replay, execute a replay agent in the command line with the exported replay definition file. TSAM Plus replay agents are under $TUXDIR/bin/. There are two kinds of agents:

•	tsamreplayagent

It supports tpcall()/tpacall()/tpgetrply() calls.

•	tsamreplaywagent

It supports tpcall()/tpacall()/tpgetrply() calls in the workstation mode.

Before running a replay, make sure the target Tuxedo domain is started up. If TSAM Plus metrics are expected, you must create corresponding policies in TSAM Plus.

Note:

The evaluation unit of throughput, latency, success/fail number is the whole replay definition, not one call in it.

Table 8‑3 lists the replay agent parameters.

 

Table 8‑3 Replay Agent Parameters

Parameter	Description
-p	Invokes the execution plan file when running a replay. Refer to Execution Plan File.
-f	The path of the security profile to be generated. Refer to Replay Security Profile.

Execution Plan File

An execution plan file stores a replay execution plan attributes. The attribute format is "NAME=VALUE". The attribute name is case-insensitive.

There are two types of execution plan modes, normal mode and stress test mode. Table 8‑4 lists the general attribute.

 

Table 8‑4 General Attribute

Attribute	Description	Default Value
definitionFile	Definition file name

 

Normal Mode Attributes

The normal mode is the default mode. It is normally used to do unit test or diagnostic a service call. It can also be used to do a stress test by setting the parameters concurrency number and repeat times to huge values.

 

Table 8‑5 Normal Mode Attributes

Attribute	Description	Default Value
concurrencyNumber	Concurrency number	1
repeatTime	Repeat time	1
sleepTime	Sleep time when repeating in seconds	0
compareReply	Compares the reply with the one in the replay definition	False

Following is an execution plan file example:

definitionFile=def1.xml

concurrencyNumber=10

repeattime=100

sleepTime=0

compareReply=true

Stress Test Mode Attributes

There are three test mode types:

•	Increase the load till the throughput does not increase any longer.

Following is an execution plan file example:

definitionFile=def1.xml

timeWindow=20

minCurrency=10

maxCurrency=1000

iniCurrency=10

totalRunTime=3600

•	Increase the load till the max/average latency reaches the specified value. It is enabled when the parameter maxLatency or avgLatency is specified.

Note:

If both maxLatency and avgLatency are specified, maxLatency is ignored.

Following is an execution plan file example:

definitionFile=def1.xml

timeWindow=20

minCurrency=10

maxCurrency=1000

iniCurrency=10

maxLatency=1000

avgLatency=500

totalRunTime=3600

•	Run with the specified throughput. It is enabled when the parameter throughput is specified.

Following is an execution plan file example:

definitionFile=def1.xml

timeWindow=20

throughput=1000

totalRunTime=3600

 

Table 8‑6 Stress Test Mode Attributes

Attribute	Description	Default Value
timeWindow	Load increasing/decreasing time window in seconds	30 seconds
minCurrency	Minimum concurrency number limitation. The concurrency number is always not less than it.	1
maxCurrency	Maximum concurrency number limitation. The concurrency number is always not greater than it.	10240
iniCurrency	The initial concurrency number when the replay starts.	1
maxLatency	Maximum latency in microseconds
avgLatency	Average latency in microseconds
throughput	Run with the specified throughput per second
totalRunTime	Total running time in seconds	No limitation

Replay Security Profile

genreplayprofile is under $TUXDIR/bin. Its parameter is the path of the security profile to be generated. When genreplayprofile is launched, you are prompted to enter the Oracle Tuxedo application password, user name and user password. It generates the replay security profile with the inputted content. The inputted content is used by the replay agent to do tpinit(). If different user names are specified in the replay security profile and the replay definition, the one in the replay security profile takes effect.

Replay Execution Result

Replay execution result is outputted to the standard output after the replay is finished or cancelled.

The normal schedule mode result contains the following contents:

•	Submit Time

•

End Time

•	Success number

•	Failure number

•	Throughput per second

•	Average latency in microseconds

•	Identical replies

•	Different replies

The stress schedule mode result contains the following contents:

•	Detailed information in every 30-second execution time window, including:

•	Current time Success number

•	Failed number

•	Throughput

•	Average latency

•	Concurrency number

•	Replay summary

•	Submit Time

•

End Time

•	Success number

•	Failure number

•	Max Throughput per second when the test is ending

•	Throughput per second when the test is ending

•	Minimum latency in microseconds when the test is ending

•	Maximun latency in microseconds when the test is ending

•	Average latency in microseconds when the test is ending

•	Concurrency number when the test is ending

Running a Replay in Auto-Created Test Domain

You can use the tool tlgdomgen.py to create a test domain to call the service in the target domain. The tool is under $TUXDIR/bin and can be run using either python or Tuxedo Script Tool (TXST).

Configuration File

Before running tlgdomgen.py, you need to create the domain configuration file.

Table 8‑7 lists the configuration file parameters.

 

Table 8‑7 Configuration File Parameters

Parameter	Description
LDOMPORT	Mandatory. Local access point port of the GWTDOMAIN in the test domain
TUXDIR	Mandatory. TUXDIR of the test domain
APPDIR	Mandatory. APPDIR of the test domain
RDOMID	Mandatory. Access point ID of the GWTDOMAIN in the target domain
RDOMPORT	Mandatory. Access point port of the GWTDOMAIN in the target domain
RDOMHOST	Mandatory. Access point hostname of the GWTDOMAIN in the target domain
IMPORTSERVICES	List of service names to be imported to the test domain, delimited by space
TSAMMGRHOST	Hostname of the TSAM Plus Manager to be connected by the test domain. LMS is not configured if this item is not specified
LDOMID	Access point ID of the GWTDOMAIN in the test domain
IPCKEY	IPCKEY of the test domain
TSAMMGRPORT	Port of the TSAM Manager to be connected by the test domain. LMS is not configured if this item is not specified

Following is a configuration file example:

[Input]

LDOMPORT = 8888

TUXDIR = /home/beadev/bea_linux64.13c/tuxedo12.2.2.0.0

APPDIR = /home/beadev/applicationgrid/domains/domain4

RDOMID = DOMAIN2

RDOMPORT = 6666

RDOMHOST = localhost

Executing tlgdomgen.py

To run tlgdomgen.py using TXST, do these steps:

1.	set Tuxedo environment:

$TUXDIR/tux.env

2.	set TXST environment:

export CLASSPATH=$CLASSPATH:$TUXDIR/jmx/jython-standalone.jar:$TUXDIR/jmx/tmjmx_tux.jar:$TUXDIR/jmx/tmjmx_metadata.jar:$TUXDIR/udataobj/tuxj/com.bea.core.jatmi_2.0.0.0.jar

3.	run tlgdomgen.py:

java oracle.tuxedo.TXST $TUXDIR/bin/tlgdomgen.py <configuration file name>

The following files are generated:

•	ubbconfig.test: UBBCONFIG of the test domain.

•	addrom.mib: MIB scripts to add GWTDOMAIN access point to the target domain.

•	setenv.test: setenv of the test domain.

•	run.sh: execution scripts to set up and run the test domain.

•	dmconfig.test: DMCONFIG of the test domain.

4.	In the target domain, run the following commands to add the test domain to the target domain:

. $TUXDIR/tux.env

export FLDTBLDIR32=$TUXDIR/udataobj

export FIELDTBLS32="tpadm,Usysfl32"

ud32 -C tpsysadm < addrom.mib

5.	Boot the test domain using the file run.sh, and then run the replay.