Filtering out specific requests, transactions, or components from the performance problem culprit list is accomplished using the stripping technique. You can read about the Drill Down method, where we start with a problem and keep looking for the source until we find it, in the previous post. But what to do if more than one serious problem arises during the test? The drill down approach may take longer than expected. In this situation, you should prioritize the most important problem and leave the others on hold. In this situation, you should use the ‘Delete method’.
It has been observed that 20% to 30% of newly developed systems and applications have numerous performance issues. Some are extremely important, while others receive the least amount of attention. This approach has evolved because engineers cannot focus on all defects at once and can provide effective solutions in a short period of time. Some solutions make old defects reappear.
Why not just delete Method?
We use the Eliminate approach to quickly and effectively reduce the percentage of bottlenecks. With this technique, you can choose which bottlenecks need to be fixed immediately and which ones can wait until the next release by applying your cognitive skills and being as creative as possible. So it can be like removing constraints related to hardware resources and focusing only on bottlenecks related to software resources. You can choose to fix the database server bottlenecks first and then focus on the application server, or you can choose to fix the server bottlenecks first and focus on the code later. Whatever you decide to remove, however, should not go unnoticed.
I would never recommend ignoring performance bottlenecks as it is one of the ways to do performance test analysis. To make sure developers are aware of open issues and can address them in the next release, simply list them, note them in the approval report, or leave them open in QC/PC.
Let’s take an example
where we discovered numerous performance limitations in an application. The program fails because it cannot handle the stress test load, which is the first bottleneck. Although the payment page in the load test has some problems (504/Gateway Timeout).
The second problem is more important than the first. especially since the payment gateway is involved. The User Experience Index is negatively affected by any payment processing errors in the real world. Stress test issues can be postponed because the application can manage the maximum load (current load) in the load test. According to the stress test problem, the program cannot handle the expected load. As a result, remove the load issue from the stress test and focus your efforts on resolving the Gateway issue first.
Another example is when there are two bottlenecks. Memory leak during soak test and high CPU usage during load test. According to specifications, the peak load of this application is 500 users, with peak hours between 900 and 1200 and between 1 and 5 in the morning. In this case, first, make the app responsive to 500 users and reduce CPU usage. Over a period of time, the memory leak problem can be resolved.
Conclusion:
the kill method does not emphasize ignoring performance issues, no matter how small. He advises setting aside the low-priority issue until the developer addresses the major issues. The Remove method works well to resolve urgent issues in a short time
