To succeed in a T24 Transact Core Banking Performance Tuning Project, you must study the endgame
- Josef Mayrhofer
- Feb 24, 2022
- 4 min read
Updated: Apr 14
In one of our recent projects, our customer's expectation was:
"After the migration from our current TAFC based system to the new TAFJ core banking engine, the throughput must be 200 or more transactions per second. "
TAFC is the 20-year-old banking engine from Temenos. It is implemented in C and, in many cases, built for best throughput. Its system architecture is dated, and customers looking for modern features are asked to migrate to the new Java-based TAFJ banking engine.
In an ideal world, such a migration should be doable without major surprises, but in reality, functional and performance issues are a common task to solve. For example, TAFC was a two-tier system, but TAFJ has better vertical and horizontal scalability options. Therefore, you can easily imagine that more tiers equal higher complexity, and based on our experience, a specialized TAFJ core banking tuning expert should be engaged.
Chess Grandmaster José Raúl Capablanca put it well: to succeed, "you must study the endgame before everything else."
This blog post outlines why endgame thinking is crucial for performance tuning and provides insights into how we speed up T24 Transact for high performance and best throughput.
Ingredients for your T24 Transact tuning success
- Observability first
- Java, Messaging, OS, Database experts
- T24 Transact experts
- Performance engineers and architects
- Business team
Our world is getting more complex every day, and the same is true for finding performance bottlenecks in distributed systems. You will find yourself dealing with everything from the low-level OS to user experience and design. Performance engineering is a complex discipline, and this is why you can quickly go in the wrong direction. As always, if complexity is high, you must try to simplify things, create transparency, and focus on the most important aspects first.
In a T24 tuning world, we are cutting out all the noise in the first place, which means we are removing everything except a single leg. One app server, one MQ server, and one Database only.
Overfitting
Focusing too much on high throughput numbers can push you in the wrong direction. I learned this lesson in one of our recent projects. Our customers expected hundreds of requests per second, and therefore he decided to maximize all pool sizes he could find. Unfortunately, the impact of this overfitting exercise was fatal because the T24 core banking engine could not process more than 20 transactions per second no matter how many Jmeter threads were pushing messages to this T24 system. So remember that you should not configure these MQ, JMS, thread, and EJB pools to the maximum.
Find distinct ways to go from zero to one
If performance is not there, things can escalate fast. You will find yourself working as a firefighter and dealing with all kinds of fingerpointing questions. This is when you must stay calm and layout the tuning strategy. Usually, we must understand the exact performance requirements for this core banking system. Once the why and how's are on the table, we review the plan and application design. Everything must be crystal clear from messaging down to Database and operating system.
Ramping up realistic load patterns designed for application tuning
You will run into big trouble if you simulate a too high or low load pattern. The former means tuning for the wrong business, and the latter means missing essential bottlenecks. Finding the appropriate transaction mix and workload model is not a simple task. Sometimes this is more an art than a science. Even business teams or architects don't have transaction patterns and predictions about the current and future usage of the new T24 core banking engine handy. But, if you would like to succeed on your performance tuning journey, you must get this vital step right. Prepare yourself for several interviews to clarify online, channel, and batch usage models.
Collect and investigate key performance metrics
You've implemented load testing scripts for your T24 core banking engine. Are you simply pushing stress tests to see how your banking engine behaves? From my perspective, you should start small and investigate single-user requests. Are some recommendations already violated agreed performance requirements? If so, don't start a load test. Investigate these bottlenecks and escalate them to the dev team. One such fundamental problem is eliminated. Next, you must turn the lights on and bring transparency to all the layers. Not only infrastructure monitoring but also application performance monitoring is required. Finally, you run your agreed load tests using increasing and steady-state workload models to determine how the system behaves. You must focus on the four golden signals: response time, error rate, throughput, and utilization.
Understanding the more significant patterns behind metrics
What to do if response times or throughput requirements cannot be held? As always, there is no precise answer. You can scale your services vertically or horizontally. If this does not help, you must investigate layer by layer. Is the slowness due to long-running database queries? Do you not see the expected throughput? Is the application caching strategy working? Are you hitting pool limits, and how is your system resource utilization during a load test? You must understand the holistic view before you initiate your optimizations. For instance, if TPS is low and response times are high, scaling would not bring a significant improvement. In such cases, you must turn to your code and configuration to detect the root cause of this slowness. Once the speed is there, you will get the expected throughput.
Cutting this story short, going from Zero to One in a T24 performance tuning project involves
- Simplify things
- Design your workload model
- Setup and execute load tests
- Collect metrics of all layers
- Optimize the system
- Re-testing and further tunings
Thanks to the enhancements in AI, we have modern observability and tuning tools in place. They promise to detect the root cause of problems and tune your applications automatically. However, this is not yet true, so the human brain and experience with such solutions are crucial for successful performance optimization.
Is your T24 Transact core banking engine not performing as expected? Contact our team today. We are here to help you and optimize your business-critical services for high throughput and optimal speed.
Happy Performance Engineering!
Josef: Thanks for your very good blog entry. I am currently working for a bank migrating T24 from R11/TAFC to R21/TAFJ. My concern is about your sentence "T24 core banking engine could not process more than 20 transactions per second no matter how many Jmeter threads were pushing messages to this T24 system". The bank I work for is not so big and no doubt it executes more than 20 transactions per second. The number is something between 30 and 60 TPS depending the time of day. How could we make T24 process more than 20 TPS?. Could we horizontally scale the T24 engine?. What could we do?. Thanks for your comment, Sergio Uassouf, Banco Credicoop (Argentina), Principal Architect