About
Rapid Bottleneck Identification is a performance analysis method.
Articles Related
The RBI Testing Approach
Traditionally, performance testers focused on concurrent users as the key metric for application scalability. However, if a majority of application and system-level issues are found in throughput tests, a new approach is needed. These three principles form the foundation of the RBI methodology.
- All Web applications have bottlenecks.
- These bottlenecks can only be uncovered one at a time.
- Focus should be placed where the bottlenecks are most likely to occur.
Although recognizing the importance of concurrency testing, the RBI methodology first focuses on throughput testing to root out the most common bottlenecks, followed by concurrency testing to assess performance under load conditions that reflect the actual number of users expected on the application. RBI testing also starts with the simple tests and then builds in complexity so that when an issue appears, all the other possible causes have been ruled out. Focusing on throughput testing, followed by concurrency testing, and using a structured approach to the test process ensures that bottlenecks are quickly isolated, which improves efficiency and reduces cost.
Reduce Testing Time
How much time can you save by focusing initially on throughput testing? Take an example of a system expected to handle 5,000 concurrent users, with users spending an average of 45 seconds on each page. If the application has a bottleneck that will limit its scalability to 25 pages per second, a concurrency test will find this bottleneck at approximately 1,125 users (25 pages per second at 45 seconds per page). In the interest of not biasing the data, a typical concurrency test ramp up should proceed slowly. For example, you may consider ramping one user every five seconds. In this example, the bottleneck would have occurred 5,625 seconds or 94 minutes into the test (1,125 users at 5 seconds per user). However, to validate the bottleneck, the test would have to continue beyond that point to prove that the throughput was not climbing as users were added. A throughput test could have found this problem in less than 60 seconds.