Fastest Way to Carry Out Application Performance Testing

This article introduces you to an efficient way of conducting application performance testing that reduces your testing efforts.

Imagine this situation: You are about to launch a Web Application. The application’s performance is crucial but you have very limited time to meet deadlines? How will you optimally execute the performance test?

Fastest Bottleneck Finding (FBF) is a new testing methodology that allows performance testing professionals to very quickly reveal the limitations of the web application’s performance. Using this approach, organizations can reduce application performance testing time and cost as well as find bottlenecks quickly.

Traditionally, performance testers focused on ‘concurrent users load’ as the key metric for application performance. They used most of their time on complex script preparation, preparing test data, executing tests for long hours and coming up with response time results. This was an easy escape for the bottlenecks to go unnoticed. It has been proved that the majority of application and system-level issues are found in throughput tests.

FBF methodology first executes throughput testing to find out the most common bottlenecks, followed by concurrency testing to measure performance under load conditions that execute the actual number of users expected on the application. This test process ensures that bottlenecks are quickly isolated, improves efficiency and reduces cost. Throughput testing requires minimizing the number of user connections to a system and maximizing the amount of work done by those users. This utilizes the system and application to its full capacity so that all issues are revealed.

A throughput test can be set up with minimum effort as compared to using the traditional approach which includes creating complex scripts, preparing test data etc. During the throughput test execution, server performance limitation is revealed within five minutes. In a traditional test, the time taken is longer as the tester first creates scripts for complex functionality, prepares test data and then executes load test with different user loads.

Once the throughput test is over and the server limit is found, performance test should be paused until the server tunes up. After the throughput test is cleared, the next step is to run a concurrency test with realistic application functionalities. Start with a load test for a simple transaction , and then move to more complex ones. This concurrency test checks the ability to handle multiple users and their transactions once the application is live.

• • Speed and accuracy

The FBF methodology enables the fastest yet thorough testing that uncovers all system and application issues—both simple and complex.

• • Cut down testing time

A throughput test finds bottlenecks in less than five minute. (Note: The identification time is valid for most cases but it could vary)

• • Wipe out initial testing complexity

Performance testing often begins with overly complex scenarios exercising too many components at the same time; making it easy for bottlenecks to hide. Hence using the throughput testing technique we can wipe out the initial testing complexity.

• Start Performance Test before the application is deployed/not yet ready

The FBF methodology sets out with system level testing that can be carried out before the application is even deployed.

The FBF methodology improves application performance testing efficiency by first executing throughput test to find bottleneck, where it is mostly likely to fall out. Once the throughput test is complete, you can focus on concurrency test to measure performance under realistic user loads and application concurrency limit. By this structured approach from system testing to application testing, you can quickly isolate bottlenecks and their associated root cause.

Assume you are going to test a system expected to handle 10,000 concurrent users, with 30 seconds page view. If the application has a bottleneck that will limit or degrade its performance to 48 pages per second, a concurrency test will find this bottleneck at approximately a 1000 users after running 1 hour test while throughput test will find this bottleneck in approximately 5 minutes.

In the above figure, Throughput tests for 100 users with 1-second page views show a bottleneck at 60 pages per second after running test for 3 minutes. Test ran with an image file request and static page request, it took minimal efforts to prepare the script.

Concurrent tests for 1000 users with 30-second page views show a bottleneck at 48 pages per second after running test for 1 hour. Scripts were prepared to simulate realistic user load. It took significantly higher efforts than throughput test for preparing complex scripts and waited until the final version of application was deployed on server.