HOW TO Use JMeter to Load test T24

Information in this document is subject to change without notice.

No part of this document may be reproduced or transmitted in any form or by any means, for any purpose,
without the express written permission of TEMENOS HEADQUARTERS SA.

COPYRIGHT 2007 - 2008 TEMENOS HEADQUARTERS SA. All rights reserved.

Table of Contents

Document History..................................................................................................................... 3
Introduction & Prerequisites.................................................................................................. 4
Software Requisites.................................................................................................................. 4
Recording of Transaction – Capture and Test a T24 Transaction............................4
Modification of the captured script........................................................................................... 11
Replay the modified script ‘n’ number of times........................................................................15
Configure, Tune and Execute Scripts – Full Load Test T24.....................................16
Configuring System................................................................................................................. 16
Configure Injector Machines................................................................................................ 16
Configure JVM & Jmeter.................................................................................................. 16
Configure Registry........................................................................................................... 18
Configure Webserver........................................................................................................... 18
Configure MQ Server.......................................................................................................... 20
Configure AppServer........................................................................................................... 20
Configure T24 data.............................................................................................................. 21
Jmeter - Adding Counters, Assertions and User defined variables to the Testplan..........21
Optimizing and Running the Script......................................................................................25
 Document History

Author Version Date

Natarajan PK V.01 11 Feb 2008

Thiagaraj J Reviewed V.01

Natarajan PK V.02 10 Jun 2008

Thiagaraj J Reviewed V.01

Copyright © 2008 TEMENOS HEADQUARTERS SA

Warning: This document is protected by copyright law and international treaties. No part of this
document may be reproduced or transmitted in any form or by any means, electronic or mechanical,
for any purpose, without the express written permission of TEMENOS HEADQUARTERS SA
Unauthorized reproduction or distribution of this presentation or any portion of it, may result in
severe civil and criminal penalties, and will be prosecuted to the maximum extent possible under
applicable law.” Information in this document is subject to change without notice.

3 Natarajan PK | Performance and Sizing Team

 Introduction & Prerequisites
The intended purpose of this document is to know how to load test T24 using JMeter by the injection
of pseudo-random data into the T24 System. The user requires basic knowledge on the operational
issues of T24 Browser (Since we’re going to send requests to T24 system using JMeter via T24
Browser). The entire procedure of this data pumping involves three major steps.
 Recording of Transaction
 Modification of the captured script
 Replay the modified script ‘n’ number of times

Software Requisites
 T24 (V R08 used here)
 T24 Browser ( V 1.7 used here)
 Apache Jmeter (V 2.3.1 used here (Can be downloaded from
http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi ))

Documentation: http://jakarta.apache.org/jmeter/usermanual/index.html
Tutorial: http://www.informit.com/guides/content.aspx?g=java&seqNum=269

Scenario: Let us consider a simple scenario of injecting 100 FT’s into the T24 System.

Recording of Transaction - Capture and Test a

T24 transaction
First we need to route the internet explorer to another proxy as follows

4 Natarajan PK | Performance and Sizing Team

 Here the ip is the ip of the machine where the tomcat is running and the port number can be given as
some other number than the default port number of tomcat (8080). Here we’ve given 9080. So IE
from now on will route the output to 9080.

We need to capture the output coming at 9080 using Jmeter. For this we need to configure JMeter
as follows.
 Add a Thread group to the Test Plan

 Add a Recording Controller to the Work Bench

 Add a HTTP Proxy server to the workbench

5 Natarajan PK | Performance and Sizing Team

  Type 9080 in the port number and START the proxy server. JMeter now starts
listening to port 9080.

 Login to browser using login page (Currently the latest version of browser (2.1) is not
working with JMeter. So for time being we use Browser version 1.7).

 JMeter starts recording all the output to Recording controller as follows

6 Natarajan PK | Performance and Sizing Team

 Optional : We don’t want the display files like like gif, html, js , css etc. for sending requests
(BrowserServlet is enough). We can exclude these unwanted files for sending our requests in the proxy
server by adding them in the exclude pattern of HTTP proxy server as follows

 Input a Funds Transfer as follows and commit the transaction.

7 Natarajan PK | Performance and Sizing Team

 After the Txn is completed, Signoff from T24. The recording of script in the following sequence is
comlpted now.
 Login Page
 Signon
 Input New FT
 Commit FT
 Signoff from T24.
For each and every action defined above, a separate BrowserServlet would be there in the recorded
script. If we run those requests alone in Jmeter now, the transaction would be pumped into the T24
system successfully. But we need to parameterize our script for Injecting pseudo-random data. Hence
we need to do the following changes to the script.
Copy the Browser Servlets alone into the Threadgroup. The following are the mandatory requests for
an FT transaction. We can disable the other servlets (Used for webvalidation, Banner display, Menu
Dispaly etc)

Login Page

Login

8 Natarajan PK | Performance and Sizing Team

 FT Input

FT Commit

9 Natarajan PK | Performance and Sizing Team

 SignOf

We may rename the Corresponding name of the requests to meaningful names (Path should be
same. Only name can be changed).

10 Natarajan PK | Performance and Sizing Team

 Recording of the Script is over now.

Modification of the captured script

The scenario we’re trying to simulate is as follows.
We have 10 users. They will work in 10 different machines (threads) and input 10 FT’s each (Totally
100 FT’s).
We need to pass Dynamic data to the T24 system to validate this random data.
So we input 10 threads in the threadgroup.

11 Natarajan PK | Performance and Sizing Team

  Add two CSV data set Config – One for Sign on and another for FT.

We need to create two CSV files (One for Sign on and other for Dynamic fields of FT).
Userpass.csv – Format {Signon Name, Password , User Name}

IdAC.CSV – Format {ID,Debit AC No, Credit Ac No}

 Specify the columns as Variables in corresponding CSV data set config elements.

12 Natarajan PK | Performance and Sizing Team

  Most Important – Change the variable values accordingly in the corresponding fields
as follows.
For example, the field value for the variable signOnName – NATARAJ01 (in BrowserServlet) needs to
be changed as $ {USER} so that when processing the particular thread, the corresponding user name
(NATARAJ01) would be passed dynamically by Jmeter from the 1 st row of CSV file. When processing
Next thread, the next value would be picked up from the next row of the CSV file (NATARAJ02).

 The same changes needs to be done for Password - ${PASS}, User - ${NAME},
transactionId - ${FTID} , fieldName:DEBIT.ACCT.NO - ${DRAC}, and
fieldName:CREDIT.ACCT.NO - ${CRAC} (Wherever they appear)
 A loop controller needs to be added for the FT part since each user would process 10
requests.

13 Natarajan PK | Performance and Sizing Team

  Important: Add a HTTP Cookie manager to play each request with the same session
ID

 Finally some listeners need to be added to the script to track the output (Requests
and also the response can be seen using a Tree listener.

Save the Entire Testplan as Jmx script. Our final Script looks as follows. Sample Script and CSV files are
attached below.

14 Natarajan PK | Performance and Sizing Team

 Pzero32 100FT.jmx userpass.csv IdAc.csv

Replay the modified script ‘n’ number of

times
For Running the script,
 Start Tomcat
 Start TCServer
 Change the LAN SETTINGS of Internet Explorer to “Automatically Detect Settings”
and close IE.
Goto Jmeter,
 RUN -> CLEAR ALL
 RUN -> START

The scripts would be pumped in to the T24 system and we may watch the process in the Tree listener.
And also if there are any problems, we can check them out at Response Data.

15 Natarajan PK | Performance and Sizing Team

 Configure, Tune and Execute Scripts – Full
Load test T24 using multiple threads and
Transactions
Scenario: Let us consider a scenario of injecting 162000 FT’s into the T24 System.

Configuring System
Before starting a full load test using Jmeter, the following needs to be configured properly to run the
test without any errors.
 Injector machines – Registry and JMeter
 Webserver – Websphere or Tomcat and T24 Browser
 MQ server (If used)

16 Natarajan PK | Performance and Sizing Team

  AppServer - TCServer

Configure Injector Machines

Before starting the test, we need to decide the number of parallel connections that we’re going to use
for the load test. This needs to be decided accordingly to the injector machine’s capability and the
number of parallel users (threads) that we’re going to use.

Configure JVM & Jmeter

For the above scenario, let us consider that we’re going to use 4 injectors for inputting 162000
transactions (Distribution of load among 3 injectors). So each injector needs to be perform 40500
transactions. Users(Threads) per injector needs to be configured accordingly with the capability of
injector machine and number of connections that the webserver and appserver can handle at a time.
For keeping the number of loops to be minimum (Increase in loop increases the heap memory of Java
virtual machine), let us have 300 users performing transactions simultaneously. The rampup period is
an important parameter which decides the time to load the specified number of threads within the
rampup period. For example, here we have 300 threads and 30 seconds as rampup period. So Jmeter
will load all the 300 threads within 30 seconds.

Every user (Thread) needs to perform 135 transactions each for which we configure the loop controller
inside script to perform 135 loops so that each injector will input 40500 transactions with 300 users.

17 Natarajan PK | Performance and Sizing Team

 If we have so many assertions and loops inside our testplan, Since Jmeter is a java based application,
JVM will require a lot of heap memory to execute the testplan which results in the crash of heap
memory(OutOfMemory exception). So we need to configure some JVM specific parameters in
jmeter.bat as follows.
Increase Heap Memory
set HEAP=-Xms512m -Xmx1024m
Enable explicit Garbage collection
set GC=java -Xcompactexplicitgc -Xrs
set ARGS=%GC% %HEAP% %NEW% %SURVIVOR% %TENURING% %EVACUATION% %RMIGC% %PERM
% %DDRAW%
Increase the evacuation ratio for Garbage collection
set EVACUATION=-XX:MaxLiveObjectEvacuationRatio=50% (or even 100% can be specified)

For understanding the Garbage collection and tuning heap size, the following link is useful.
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

Configure Registry
Since we configured 300 users, that many simultaneous TCP connections should be there to send the
request to the webserver otherwise this will also result in heap memory crash. For increasing the Tcp
connections, and increase the data size that the tcp can transfer, We need to add two new DWORD
values In the following path and restart the injector machine.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
1. TcpNumConnections – 300
2. TcpWindowSize – ffff (Determines the largest TCP receive window that the system offers. The
receive window is the number of bytes a sender can transmit without receiving an
acknowledgment. This entry overrides TCP's negotiated maximum receive window size and
replaces it with the value of this entry)

18 Natarajan PK | Performance and Sizing Team

 For understanding the parameters for tcp, the following link is useful
http://support.microsoft.com/kb/314053

Configure Webserver
 Increase the max sessions of T24 browser in channels.xml accordingly with the no of sessions
allotted for our browser channel in TCServer as follows (if you’re using browser channel).
<CHANNEL>
<NAME>browser.1</NAME>
<TIMEOUT>12000</TIMEOUT>
<ADAPTER>
<TYPE>tcp</TYPE>
<PORT>10001</PORT>
<SUPPLIER>
<INITIATOR>
<HOSTNAME>10.9.1.7</HOSTNAME>
</INITIATOR>
</SUPPLIER>
<CONSUMER>
<MAX_SESSION>40</MAX_SESSION>
<ACCEPTOR>
<BACKLOG>30</BACKLOG>
</ACCEPTOR>
</CONSUMER>
</ADAPTER>
</CHANNEL>
For MQ, this is not required. A sample config of MQ is as follows.
<CHANNEL>
<NAME> channel3q1 </NAME>
<TIMEOUT> 30 </TIMEOUT>
<ADAPTER>
<TYPE> mqseries </TYPE>
<MQHOST>10.0.1.12(1414)</MQHOST>
<MQMANAGER>t24.mq2.queue.manager</MQMANAGER>
<MQQUEUE>channel3.queue1.in</MQQUEUE>
<MQCHANNEL>t24.mq2.client</MQCHANNEL>

19 Natarajan PK | Performance and Sizing Team

 <CONSUMER>

<!--
<REPLYQUEUEPARAMETERS>NONE</REPLYQUEUEPARAMETERS>-->
<!--
<REPLYQUEUEPARAMETERS>ALL</REPLYQUEUEPARAMETERS>-->
<!--
<REPLYQUEUEPARAMETERS>QMANAGER_QUEUE</REPLYQUEUEPARAMETERS>-->
<REPLYQUEUEPARAMETERS>ALL</REPLYQUEUEPARAMETERS>

<MQHOST>10.0.1.12(1414)</MQHOST>
<MQMANAGER>t24.mq2.queue.manager</MQMANAGER>
<MQQUEUE>channel3.queue1.out</MQQUEUE>
<MQCHANNEL>t24.mq2.client</MQCHANNEL>
</CONSUMER>
</ADAPTER>
</CHANNEL>

 Increase the number of threads and JVM heapsize in the webserver. The parameters are
different for different webservers .

1. For Apache Tomcat

Edit the following file – <Tomcat Dir>\conf\server.xml
<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
<Connector
port="8080" maxHttpHeaderSize="8192"
maxThreads="300" minSpareThreads="50" maxSpareThreads="75"

Increase the heapsize – Min & Max memory pool

20 Natarajan PK | Performance and Sizing Team

 2. For Websphere
Use Websphere console and increase the threadpool size and JVM size from the console
itself.

Configure MQ Server
We need to add a separate queue for MQ server for handling web based transactions. If needed, more
channels per webserver channel can also be added (in case we’re going to use separate channels for
separate transactions)

Configure AppServer
The tcserver.xml file in tcserver needs to configured accordingly with separate adapters and
sessions. Need to decide and increase the number of sessions in tcserver in accordance with
the mix of transactions and requirements. And also the heap memory and garbage collection
needs to be tuned in a similar manner (of Jmeter.bat) for tcserver too in order to avoid the
crash due to JVM heap memory (since tcserver is also a java based application)
TCServer.sh
nohup java –Xms512M –Xmx1024M -Xcompactexplicitgc -Xrs
-Djava.endorsed.dirs=../lib/endorsed/jaxp13:../lib/endorsed/jaxb13 -jar ../lib/tcserver.jar -d&
And most importantly, we need to have sequential data in T24 to perform simultaneous and
multiple transactions. The following changes needs to be done.

Configure T24 data

We need to have sequential users in T24 system. For example in our scenario, if we’re going
to use 300 users, we need to have 300 sequential users in the system. Eg:
PUSER1,PUSER2,PUSER3,PUSER4…

21 Natarajan PK | Performance and Sizing Team

 And also we can have other relevant data required for our transactions such as Accounts
sequentially, so that we can just use counters in our Jmeter scripts for passing dynamic
variables as Ids.

Jmeter - Adding Counters, Assertions and User defined

variables to the Testplan
If we have data sequentially in our T24 area, we can add Counters and pass the data dynamically
instead of using CSV file.
Scenario - Users are in the following order – PUSER1, PUSER2, PUSER3 , PUSER4… and we’re going to
perform the FT transactions.
FT id’s needs to passed sequentially as follows - FT072691000000001, FT072691000000002,
FT072691000000003, FT072691000000004…

Add a Counter

Setup the Increment and number format as follows (Number format is the format of the counter
variable. For example, if we set 1 as the start and increment 1 with format 00000000, the output of
the counter variable for every iteration (or loop) would be in the following order – 000000001,
000000002, 000000003, 000000004…. )

22 Natarajan PK | Performance and Sizing Team

 Setup a user defined variable as follows

In the request, replace the transactionId with the following variable

${FTID}${C2} -- Here ${FTID} is constant – FT072691 and Counter(C2) varies for every iteration.
Hence, we would get the FT Id in the following sequence for the iterations.
FT072691000000001, FT072691000000002, FT072691000000003, FT072691000000004…

23 Natarajan PK | Performance and Sizing Team

 Similarly, for login request, the users can be passed dynamically using counter as follows.

24 Natarajan PK | Performance and Sizing Team

 In the above example, password is same (123456) for all users and the signon name will be passed
dynamically with the following variable - PUSER${C1}

The values will be in the following sequence for the above example..
PUSER10001, PUSER10002, PUSER10003, PUSER10004…

Adding Assertions to the TestPlan

In the event of an error from the T24 application side and also from Jmeter side, the scripts were
configured with assertions, which will report immediately, if an error occurs. Using these assertions
the % error can be calculated easily at the end of each test run, but putting more assertions might
slow down jmeter scripts so this needs careful planning while recording and designing the Jmeter Test
plan. The assertion will analyse the response message that Jmeter gets as a result of posting the
message and reports the error according to the configuration that we’ve done in the assertion.
To add an response assertion to the Http request, do the following

25 Natarajan PK | Performance and Sizing Team

 After adding an assertion, we can search the response to ‘contain’ or ‘not’ contain the given text.
Jmeter will search the given text in the response and marks the request as ‘failed’ so that we may
know whether the request completed its job successfully or not. (For eg: If we send a login request to
T24, the request may fail from T24 side due to some Security violations. But for Jmeter, the transaction
was successfully posted so it marks the request as success (Green in Tree listener). But the request
has not done its Job in T24 side. In this scenario, adding an “Security violation’ Assertion would report
the request as ‘Failed’ (Red in Tree Listener) so that we may analyse and sort-out the problem
accordingly)

Optimizing and Running the Script

The following things needs to be done before running a test.
1. Unwanted assertions and listeners should be removed from the script. For T24, ‘SECURITY
VIOLATION’ and ‘RECORD IS LOCKED’ assertions and ‘Summary report’ listener is enough. The
listeners such as tree listeners and Graph listeners would take much time and memory.
2. Add a delay of say – 5000 ms in the script by using a ‘constant timer’ which ensures the user
delay before sending the requests for the transaction.
3. Clear the log , protocol and Tec files before running to avoid signon problems and to
determine any problems while running the test.
4. Clear all output from previous Jmeter tests by the RUN->Clear all option.
5. Run the test.

A sample optimised script for FT is attached below.

FT1Web1.jmx FT1.csv

26 Natarajan PK | Performance and Sizing Team

27 Natarajan PK | Performance and Sizing Team