Embed Size (px)
Citation preview
Top 7 performance bottlenecks in Payments and Treasury Banking
Applications: QA practitioners viewpoint
Seetha Gurunathan
Infosys Limited (NASDAQ: INFY)
1
AbstractComplex banking applications involve large multi-layered architecture and multiple servers. The data handled by the banking application is also extremely huge with zero scope for error. Increasing focus on internet banking has resulted in the need for extremely stringent performance testing of these applications. Though it is complex, most of the systems have a set of common performance bottlenecks, if addressed, will lead to great improvement in performance. Various complex activities like payments management, receipts, treasury, payments initiation and trade services have to be performed in real time through the internet setting the benchmark for zero performance issues. Often, the most neglected part of performance testing is taking into consideration the diverse nature of a multi-layered architecture across multiple interface points. Complex business logic for most commonly occurring activities like payments processing also demand performance and accuracy. Database performance testing as a result, is of prime importance and focus on transactions rich in interface points would result in more accurate performance testing results.
2
Abstract (cont..)When we are working on payments systems, another factor to consider would be the transaction completion. We often see the break point of performance occurring in failover scenarios. Such testing stresses the importance of proper load balancing across servers. Since we are looking at availability of treasury and payment services throughout the financial year, across large volumes and multiple players, endurance testing for adequate lengths of time, with focus on interfaces with government data like bank ids will address other critical bottlenecks. Prior knowledge of where we have to look for bottlenecks along with a set of best practices ensures success in performance testing of complex applications in treasury and payments domain.
3
Target Audience
Performance Test Managers and Leads To help them understand the complexities of performance
testing large banking applications for large user volumes To guide the team in identifying critical performance
bottlenecks to reduce test effort To come up with more efficient test strategies for performance
testing
Performance Test Leads/Engineers To identify the right bottlenecks when testing large banking
applications To understand the domain complexities while executing
performance tests To appreciate the similarity between the different complex
banking applications and how performance testing can be somewhat standardized in terms of defect identification
4
What we will cover today1.Complexity of Banking Services and criticality of performance
testing2.Performance Testing – What and how?3.Top 7 bottlenecks4.Performance Tuning5.Best practices6.Conclusion7.Appendices
5
Top 7 bottlenecks and what to do with them (pop the cork!)
Objectives of the session
User expectations
Expectation from Audience
After popping the cork - Identify critical bottlenecks Apply domain flavor and stir things up Do a bit of performance tuning
7
Objective
Ensure a high performance
banking application!
Complexity of Banking Services and criticality of performance testing
Why is a banking system so complex?
Should I care about the performance?
Why is a banking application so complex? Volume of data handled Sensitivity of data Criticality of transactions Zero tolerance for error Repeated transactions of same kind 24/7 availability of all systems Large batch processes at pre-defined times
9
Solution – Performance Testing
Analyze test results and identify performance issues, bottlenecks
Arrive at recommendations at various levels like application changes, DB changes, configuration or architectural changes
Report results and identified tuning recommendations Escalate issues to client management for those requiring 3rd
party intervention
10
The top 7 – Finally!!
Huge front end pages, rich in images and other content Connection pool issues, not able to service requests Load balancer not set up correctly, resulting in skewed
performance Servers not configured correctly, Firewalls not setup correctly Queries not optimized, resulting in lots of waits and increase in
execution time Deadlocks, resulting in requests not getting completed. Inefficient stored procedures
11
Some examples where we fixed it!
• Firewall setting to be updated during server move
from Chicago to Charlotte• Bank id related transactions were failing – code fixed• Load balancing issues – web server configuration fixed• Oracle patch release leading to performance issues• DB memory leak – fixed by moving Preparedstatement to SQL
Execute Query
12
Now, what do I do with all the bottlenecks?
Performance Tuning
Best Practices
Performance Tuning
Front end page sizes are reduced Code enhancements done to eliminate hanging threads Server settings updated to handle multiple connections Queries and database stored procedures tuned Indexes leveraged for search operations
14
Best Practices Adequate knowledge of the banking
application to be tested should be gathered Adequate monitoring tools should be set up Appropriate dashboards should be constructed Load, Stress, Volume and Endurance testing should be
executed for critical transactions Failover testing should be executed for each release to ensure
server performance
15
Best Practices – there are more! Common bottleneck areas should be targeted first for analysis
and performance engineering New standard processes/guidelines/checklists to manage
requests related to Recurring Business / Application Proven processes and methodologies should be deployed to
manage new service engagement customer needs
16
End of the story – Last but not the least
Conclusion
Questions and Answers
What we learnt today
All banks rely on similar workflow transactions The bottlenecks follow a similar pattern
18
YAY!
Performance testing can be interesting and simple
19
Whew! The end –
(Now I need another coffee)
20
References
• Infosys project experience• www.infosys.com
21
