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.

Want to Learn More about Our Performance Testing Services?

Find out what’s included and how to start working with us


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. PFLB was hired to conduct performance testing.


PFLB 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. PFLB 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, PFLB 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, PFLB’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.

PFLB’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 PFLB 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.