Over the last five to six years, I’ve had the chance to work with a few applications that are into CRM and the financial closure domains. While working as a QA Lead and Scrum Master, I was able to work as a performance tester as well. Fortunately with these applications, our customers are willing to spend some time on performance engineering and monitoring through different Application Performance Management Systems that target application performance and infrastructure monitoring. In addition to the APM systems, I was also able to setup CI environments and dashboards.
In this article, I would like to share my experience with application performance monitoring and how it is connected with Performance Engineering. First of all, I will start with the main performance approaches and talk about how we can connect tools, etc. Then what I discuss from that point on will be clearly understood.
Three Performance Engineering Approaches:
In Performance Engineering, we have 3 approaches that can be used to present the entire life cycle. These are Reactive, Proactive and Predictive.
First: Reactive Approach
When dealing with software applications, there a lot of sudden performance concerns due to various issues such as requirements not being identified properly (SLA), customer database related issues, problems in the user groups or user personas, and issues when the user load increases unexpectedly. This approach is needed, but is not encouraged as the best way of ensuring product performance. Hence, we look for a second approach.
Second: Proactive approach
In this, we are targeting a sustainable way of ensuring product performance. Nowadays, when about to start a software product implementation, we need to think about the non-functional aspects more than ever. Especially the performance engineering aspects as it will trigger issues that could lead to changing the entire application architecture at the last stages. Hence, starting the performance assessments in the early stages of the life cycle is a must. In an Agile environment, we can say it should be started from Sprint 0. Not only that, it should be carried out throughout all the sprints.
Furthermore, we need to focus more on continuous performance assessments and monitoring (unit and functional level) rather than doing manual assessments by developers or testers. By using this continuous approach, we can eliminate the cost of quality and its remedies more effectively and efficiently. By using a monitoring dashboard, we can see the release or commit-wise performance figures to detect issues ASAP. It will also increase the visibility for customers who are concerned about application performance and improvements. Say for example, if we can establish a CI environment that triggers in the nightly build, we can find the performance issues easily by spotting the trend graphs rather than waiting till hardening sprint or system tests at the end of the release. As depicted in the following images, we can display figures on the dashboard: