T24 R19 - Transact

Benchmark Report
The purpose of this document is to show the performance results for R19
R19 T24 Transact Benchmark report

1 Table of Contents

1 Table of Contents ...................................................................................................................................2

2 Document History...................................................................................................................................3
3 Acronyms ..............................................................................................................................................4
4 Executive Summary ................................................................................................................................5
5 Dataset...................................................................................................................................................5
5.1 Dataset for the benchmark ............................................................................................................... 5
6 Objectives – Transactions per second .......................................................................................................6
7 Execution method ...................................................................................................................................6
8 Test case 1 Online Operation with “spikes” 1,100+ tps ...............................................................................7
9 Test case 2 High mass influx of accounts. .................................................................................................8
10 Test case 3 High volume cash dispersion ..................................................................................................9
11 Test case 4 High volume payment ..........................................................................................................10
12 Test case 5 Breaking point and recovery .................................................................................................11
13 Test case 6 Close of business .................................................................................................................12
14 System Benchmark Environment ...........................................................................................................13
14.1 Software Stack ............................................................................................................................ 13
14.2 Test data ..................................................................................................................................... 13

R19 T24 Transact Benchmark Report Page 2 of 13

R19 T24 Transact Benchmark report

2 Document History

Author Version Date

Simon Henman V 1.0 28/10/2019
Raviteja Penki V 2.0 29/10/2019
Daniel Kendrick V 3.0 29/10/2019

R19 T24 Transact Benchmark Report Page 3 of 13

R19 T24 Transact Benchmark report

3 Acronyms
TAFJ – Temenos application framework in Java
TPS – Transactions per second
AppDynamics – Application Performance Monitoring tool

Definition of a transaction.

A transaction is a request from the Mq layer to T24 and the database and back to
acknowledgment.

An example of a transaction is a balance enquiry. Once the user has logged into the system, they
request a balance and this causes a request from the user screen (Mq request) to the application
(T24) and database layer and back to the user.

R19 T24 Transact Benchmark Report Page 4 of 13

R19 T24 Transact Benchmark report

4 Executive Summary

Temenos is required to run a benchmarking exercise in 2019 on T24 RetailSuite, with the
objective of providing confidence to Any Bank that the T24 platform is able to support the
expected transaction volumes defined.

This plan represents a set of benchmarking tests where the objective is to more closely align to a
retail bank’s expected transaction types and volumes.

This exercise will:

- Show the banks Mix of transactions and scenarios scale.

- Evidence the performance of the Temenos platform on Oracle Stack.

- Demonstrate single transaction scalability

- Demonstrate vertical & horizontal scalability.

- Complete successfully the 6 scenarios required.

- Run the Oracle Database system with RAC (real application cluster) architecture on an
EXADATA server.

- Run the benchmark will full data encryption ON.

This will provide the confidence needed by the Bank in the underlying application and the ability
of the application to scale.

5 Dataset.
5.1 Dataset for the benchmark
Customers 36,024,669
Catchment Accounts 40,141,146
Credit Accounts 28,155,157
Total Accounts 68,296,303
Branches 50

R19 T24 Transact Benchmark Report Page 5 of 13

R19 T24 Transact Benchmark report

6 Objectives – Transactions per second

Below are the agreed transactions to be tested.

Transactions Number per seconds Operational

Payment on credit 624

Account to account transfer 357

Charge to account 357

Payment on account 357
Account Opening (1%) 11.5 & 18 tps

Total TPS 1,100 & 1750 +

7 Execution method
Transactions will be loaded into the queues on Mq and released to measure the throughput and
tps of the transactions.

Vertical scalability will be tested by injecting the mix of transactions into Mq and pushing the
single server to 90%+ CPU and resource busy.
To show horizontal scalability one server will be injected with transactions and increased to 90%
CPU busy, then the second will be added and injected with transactions to show the two servers
are able to handle the same amount of workload.

R19 T24 Transact Benchmark Report Page 6 of 13

R19 T24 Transact Benchmark report

8 Test case 1 Online Operation with “spikes” 1,100+ tps

Requirement: Soak test 1 hour.

The test involves a sustained load of 1,781 transactions per second during 60 min,
operating in a random way between different types of accounts, considering a threshold
of 65 million active accounts, already loaded within the system, with the distribution
established in number of accounts and number of credits.

To validate that the platform is able to maintain the operation of the bank peak during a
specific time period, without experiencing errors or conditions similar to the following:

• Unexpected errors in the system.

• Slowness in response to operations.
• Loss of information.
• Incorrect affectation of the movements. Snapshots of the application server
• Duplication of data or transactions. and the database node

Results: 1848 TPS

CPU Busy: 75%

Response time
180ms

Test Summary
Zero errors

R19 T24 Transact Benchmark Report Page 7 of 13

R19 T24 Transact Benchmark report

9 Test case 2 High mass influx of accounts.

Requirement:
Processing a batch of 12 million records for injection of accounts, which will contain a
distribution of 85% for new customers (same as shall be created during the process) and
15% for existing customers, to which you must associate the account.
The process should run coexisting with 1,104 TPS in line, during 4 h, which will be
divided into 4 separate operations, 1 for each hour of testing, changing the type of
operation to one that has not been used previously.

To validate that the platform is able to generate a high volume of accounts correctly in a
specific time while coexists with the average line operation of the bank (1,100 tps), each
account to be assigned a unique account number, which shall be determined on the basis
of a base number, to discriminate a duplicate account numbers already used by the
institution, this will allow us to understand the process of assigning account numbers.

Results

Accounts = 386 tps (386*60*60=1.382million per hour)

Mix = 1175 tps

Will require 8.5 hours to inject 12m additional customer accounts.

64294119 Records Counted Before Injection.

68296303 Records Counted After injection.

CPU: 67%

Test Summary
Zero errors

The Above Results are taken from the DBTools before and after the injection to show the
successful input of records.

R19 T24 Transact Benchmark Report Page 8 of 13

R19 T24 Transact Benchmark report

10 Test case 3 High volume cash dispersion

Requirement:
Ability to perform 1.5 million subscriptions to view accounts within the platform, received
by means of a file from a single account existing view.

The amount to be deposited in the accounts will have to vary by account, in a range from
$1.00 to $5.00 US Dollars.

This should run coexisting with 1,781 TPS online during 1h, dividing the operations for
periods of 30 min, running the 2 main operations paid to credit and charge to account, one
for each period.
To validate that the platform is capable of performing a dispersion process payroll,
through an origin account where it will undergo multiple simultaneous charges,
subscribers to different accounts destination, in such a way that the process can live
together in parallel with the operation estimated peak and the duration of the process is
equal to or less than the expectation of the institution, ensuring that the total number of
payments corresponds with the number of charges from one account to the other, as well
as identify the speed in which target accounts will be able to access funds deposited.

Results: Snapshots of the application server

and the database node
Clearing tps = 380.91 tps

Mix tps = 1869 tps

CPU 80%

Test Summary

R19 T24 Transact Benchmark Report Page 9 of 13

R19 T24 Transact Benchmark report

11 Test case 4 High volume payment

Payments – from many accounts to a single source.
Requirement:
Ability to perform 1.5 million subscriptions to a single account view with multiple
accounts charge to view existing within the platform received by means of a file.

Each payment or deposit to the account must be carried out by a concentrator in the
amount of $5.00 US Dollars.

This should run coexisting with 1,104 TPS online during 1 h, dividing the operations for
periods of 30 min, running the 2 main operations paid to credit and charge to account,
one for each period.
To validate that the platform is able to perform multiple simultaneous operations of
compost to a concentrator, through charges from multiple accounts origin, simulating a
process of collecting payments similar to a payment transaction of services, guaranteeing
the traceability and integrity of operations, which may be by different amounts, concepts
and identified by unique references for each operation. The process must be coexisting
with the estimated average transactions.
Snapshots of the application server
Results: and the database node

Clearing = 408tps
Mix = 1873tps

CPU 60%

Test Summary

R19 T24 Transact Benchmark Report Page 10 of 13

R19 T24 Transact Benchmark report

12 Test case 5 Breaking point and recovery

Reach system limits.
To identify comprehensively the limit of operations that will be able to withstand the
system without presenting errors and maintaining acceptable response times, starting
from the peak of operation than expected, running on the same hardware infrastructure
sized for 1,781 TPS, without the need for a growth.

Once you have found the point of maximum break, be able to identify the symptoms that
we will be facing a similar scenario, such as:

• Unexpected restarts any server or layer applications.

• Deadly embraces within the application.
• Data corruption.
• Duplication of operations.
• Loss of operations.
• Of queueing connections.

As well as, the conditions necessary to return to an optimal state of the operation of the
system, without the need for manual restarts any of its applicative layers, or, failing that,
to be able to describe the manual procedure that must be followed in order to restore the
optimum operation of the system.

According to the maximum number of operations of 1.781 TPS in line in parallel, there
will be a progressive increase of 100 TPS every 5 minutes until you reach the breaking
point, with a time limit for the implementation of 1 hour.

Once you have found a breaking point must be performed a progressive decrease of 100
TPS each 2 minutes until you reach the point of normal operation.

You must use the following distribution of operations during the test:

• 36% payment on credit.

• 21% account-to-account transfers (charge and compost).
• 21% charge to account.
• 21% payment on account.
• 1% opening accounts.

R19 T24 Transact Benchmark Report Page 11 of 13

R19 T24 Transact Benchmark report

Screenshot of breaking point.

13 Test case 6 Close of business

COB
Requirement:
Run the end- of-day considering the volume of accounts and clients are preloaded and
created during execution of test cases above, these must have a distribution of accounts
in such a way that the interest accruals is conducted on all accounts, however the
capitalization is only 50% of the accounts.

The COB completed as expected in 5 hours.

The extended time is due to the huge influx of accounts being added into the daily end
of day.

R19 T24 Transact Benchmark Report Page 12 of 13

R19 T24 Transact Benchmark report

14 System Benchmark Environment

All processors are x86-64 based architecture.

This will be running in the Oracle private cloud.

Server Type # Servers # Cores Memory / server Total Cores Total Memory
T24-App 12 24 32Gb 288 352 Gb

Database 2 96 2 TB 96 352Gb
Totals

14.1 Software Stack

EAP 7.3 on RHL 7.4 OS OR Oracle enterprise linux v 7.4

Oracle Enterprise Edition database 12.2.0.3.

T24 Model Bank release 2019-08

14.2 Test data

All data used in the testing was generated internally with no customer live data used at all.

This consisted of the following:-

36,000,000 customers, and a total of 68,000,000 accounts.

The database is not being populated with transaction history. The system has been built for the
benchmark objectives and history is not currently in scope.

R19 T24 Transact Benchmark Report Page 13 of 13