How to Avoid Your Financial Application Crash Under Load

We talked to our expert Xenia from PFLB’s load testing department about financial application testing. Xenia shared her experience of testing financial applications and transaction systems, along with some life hacks on how to choose the perfect timing for such performance tests.

When Is It Necessary to Test Your Financial Application?

Providers of financial services usually suggest that their customers should use both the web version and mobile application simultaneously. But in recent years the popularity of mobile applications has been climbing, and they are definitely going to take the first place eventually. That is why it is so important to test the system under load, both on the front end and on the back end. However, I’d like to focus on the back end of the financial system and its load and performance testing services. The speed of the application itself on the front end is a separate issue.

If a large number of users is working with your heavy loaded system via mobile client, performance testing becomes a must. To figure out if the number of users is large, just ask yourselves if mobile client operations are in the top list of your requests.

To run performance tests, we usually use the most highly-intensive operations. These often constitute 20% of the overall number of operations, but 80% of the load. If these 20% include requests from your mobile financial application, consider running performance testing asap.

What Is the Difference between Load Testing and Functional Testing for Financial Applications?

It’s the same as if you were testing any other client. Functional tests aim at checking if the response to a user’s particular actions is correct. Load tests help determine if your servers will be able to stand a large number of user requests. That’s why the number of users and requests is important.

And What Is the Difference between Testing the Browser Version and the Mobile App?

Roughly speaking, there is none. The main idea of load testing is to capture the traffic of user requests to the financial application servers. In the browser version, you can do it using developer’s tools, e.g., Google Chrome.

When you are recording traffic from a mobile application, it is a bit more complicated. You have to deploy a proxy server on the computer and configure the phone for it. Capture this rerouted traffic with a sniffer, for example, Fiddler. Otherwise, you can use a mobile phone emulator on your PC, then you won’t have to configure a proxy server on your smartphone. Mobile client testing is more complicated, but absolutely doable, although you should plan for more time. The rest of the process is similar to testing the browser version. We convert captured traffic into a load testing script and run the tests.

What Does One Need to Know about Load Testing of a Financial App?

There are two moments I’d like to specifically highlight. Firstly, you may need a separate build of the app that would send requests to your test contour. Performance testing is usually done in an environment that copies production as closely as it is possible. Mind that the testing process wouldn’t be effective if you use nothing but ReadOnly operations. It also complicates cleaning test data from the real system. This problem is exactly why it’s better to run tests in the copy of the production environment rather than in itself. 

Another point is that applications using ssl-pinning may cause troubles. While recording traffic, you may get a message of a connection error. However, it’s avoidable.

Why Is It Important to Test the Mobile Financial Application, Too, instead of Testing the Browser Version Only?

Because traffic from a mobile app can be very different from traffic from a browser. Hence, the load emulated during the tests will be different from real-life load. It can make all test results irrelevant. All performance testing processes may become useless.

What Questions Does Performance Testing of Financial Applications Answer?

The most important question is what maximum productivity of the back-end is, i.e., how many concurrent users can work with the system. You can also predict the system’s death date: it’s relatively easy. Let’s say that the system’s maximum productivity is 1,000 users, at the moment, there are 500, and there are a hundred new registered users per month. So the death date is in 5 months: that is when the system won’t endure the load anymore. 

Load testing helps you understand what problems limit the system’s capacity at the present moment. The term is bottlenecks. After you get rid of your system’s bottlenecks, it’s a good idea to retest it to make sure that everything works and that the death date was rescheduled to the distant future.

What Bottlenecks Do You Think are the Most Frequent?

The primary reason for productivity limitations is servers’ computational power. There are many important questions to look for answers for: you need to know how much RAM you have, how many servers there are, how many harddisks there are, and how fast they are. If it is in fact them limiting system productivity, you need to locate the resource where it happens. Unfortunately, increasing server computational power is not a universal solution, although it is relatively easily affordable. The most expensive way is to buy more hardware. But in some cases, acquiring additional resources doesn’t help either.

Other issues are specific to testing financial applications. Firstly, you need to locate the slowest transactions. You might want to use transaction testing to ensure the complete integrity and success of business transactions taking place via online mode. For example, with lots of concurrent users, authorization may be quick, while money transfers may take time, or vice versa. This would highlight problematic locations in your code. You will have to take a closer look at such places and reprofile them.

Another issue is which operations spit out errors under high loads. Let me give you an example: money transfers always work well, but cashback crushes under load. 

Sometimes the problem is not enough connections from your back-end server to the database server, or there may be problems with particular sql requests to a database server.

The number of threads might be not enough either. Highly loaded applications use several streams. To increase productivity, requests are processed simultaneously instead of consequently. You will need to increase the number of parallel streams so that the server would be able to process information faster, and then the level of productivity will rise, too. 

Often, resources are not released, or leaked. Increasing load utilizes a lot of hardware resources, for example, RAM. The system starts degrading, and another bottleneck can appear in a while. 

To sum up, let me repeat: financial application testing is a must, and although it may sound complicated, in fact it is absolutely doable. I have tested many, so trust me.

If we got you interested, continue by reading our article on “Banking Application Testing: Benefits & Use Cases”. Don’t hesitate to request a quote, if you need help with testing your application: our 400+ engineers have worked for 300+ projects. Most probably, they have already faced challenges similar to yours!