Performance testing of the transaction processing system

Our client is a big commercial bank and
a leader in the consumer credit market.  It has a presence in more than 2,000 cities, with more than 31.6 million customers.

To automate the back office for retail customer service, which supports retail transactions, personal accounts, and payments, the bank uses TranzWare CMS (a Compass Plus product). The front-end solution, which  is needed to manage terminal devices, route and authenticate transactions, and communicate with payment systems and third-party authorization hosts, runs on TranzWare Online.

Our client has s presence in more than 2,000 cities, with more than 31.6 million customers. 

Got a project in mind?

There is no better place for a QA solution than Performance Lab.
Drop us a line to find out what our team can do for you.

Challenge

Our customer decided to implement its own transaction processing. This significantly simplifies business processes and reduces costs when using external processing centers.

In connection with the planned migration to an in-house processing system, bank specialists identified risks associated with the performance and fault tolerance of the IT infrastructure, TranzWare CMS, and TranzWare Online, namely:

  • Acritical drop in the through-put of retail transactions.
  • Potential interruptions in the handling of credit/debit card transactions.

As part of its mitigation of these risks, the bank decided to conduct benchmark tests to compare the performance of the TranzWare CMS and TranzWare Online systems before and after the introduction of changes to the in-house processing system. Performance Lab was hired to conduct performance testing.

Solution

Performance Lab proposed to focus on testing the performance of two system behavior profiles: “business day” and “day-end closing”.

Analyzing the operational statistics of the live system revealed the primary sources of the load: business-user transactions and background processes being per- formed on a schedule. An analysis of the integrated communications helped determine the nature of the interaction with external systems and served as the basis for adding additional operations to the profiles.

Loads were emulated using tools such as LoadRunner, JMeter, and Citrix ICA. Performance Lab engineers used an ISO-8583 emulator, developed in-house, to generate test payment card transactions.

During the project emulators of external systems were also developed to create additional load using JDBS, SOAP, Oracle AQ, and PL/SQL.

And tools in the form of a PL/SQL package and auxiliary LoadRunner scripts were developed to generate test data in a database.

A series of tests were run on the “old” configuration. Then the same series of tests were run on the “new” architecture, which was already using the bank’s in-house processing system. This make it possible to compare the performance of the two configurations on a load representative of real operating conditions.

As the tests were run, Performance Lab specialists monitored the IT systems’ performance characteristics under load. Parameters were changed at the level of system resources (CPU, Memory, I/O), databases and middleware, applications (code profiling), and business processes (operation response times).

Based on the systems analysis, Performance Lab’s performance engineers discovered several bottlenecks.

Customer benefits

The testing revealed that the switch to the in-house processing system was degrading the performance of the front-end’s TranzWare Online system. Its throughput plummeted to less than one fourth of what it had been.

Performance Lab’s performance engineers located the bottleneck causing this degradation. It turned out to be the CBA interface responsible for TranzWare Online’s communication with one of the banking systems. During the testing, a backlog in the CBA interface’s message queue resulted in degraded performance for all types of transactions.

Moreover, the engineers found potential problems due to single-threaded processing of the one banking system transactions on the TWO application server, as well as several functional bugs. The findings presented by Performance Lab at the end of the project helped the bank decide to postpone deployment outfits in-house processing system by 3 months, during which time the bottleneck was fixed by a developer. After all of the bugs were eliminated and the load testing was repeated, the in-house processing system was successfully introduced.

Download
brochures

More information about QA solutions we provide is available in our brochures

PL CSV SOLUTION

TEST AUTOMATION SERVICES

CASE STUDY: TOP 10 BANK AT

PERFORMANCE TESTING BROCHURE

AGILE PERFORMANCE TESTING

IVR LOAD TESTING SERVICES

CASE STUDY TOP 10 BANK LT

CASE STUDY RETAIL

CASE STUDY GOVERNMENT

QA OUTSOURCING WHITEPAPER

Latest posts from us

How to Build the Best Software Testing Team: A QA Project Manager’s Guide
6 Best Mobile App Testing Tools for Android & iOS
Everything You Need to Know Before Starting API Testing
Creation of the Load Testing Profile
Why Remote Testing Services are so Important during and after Pandemic