Diagnosing, fine-tuning and fixing poorly performing IT applications is both a science as well as an art. To build software that “performs”; Performance awareness, planning and execution should be baked into each of the phases in the SDLC.
Studies indicate that 60 percent of enterprise system performance problems are related to application design. The remaining 40 percent of performance issues, which are unrelated to design, include issues with the network infrastructure and the interactions between disparate back-end platforms and operating systems that Web applications rely on. This variety of issues demonstrates the need to manage performance throughout the application life cycle. For Web application projects to be successful, such issues must be addressed early in the application life cycle.
2. THE PROPOSAL PHASE: PLANNING FOR PERFORMANCE
The success or failure of any software project rests heavily on the methodology followed for that project. Any exercise to “accurately” estimate the cost and effort required to deliver a quality software product is only as good as our interpretation of the program size and the implementation complexity.
Good estimation requires experience and judgment. We should continue to value human experience, intuition and wisdom over and above what our “processes” define.
We also emphasize on the importance of using the elaboration phase of the SDLC to
tackle potential performance issues and to nip those in the bud.
Managing performance through out the lifecycle requires that personnel at each stage contribute. Typically development teams receive a design plan that includes performance requirements that they can use as a guideline during development. After development, testing personnel evaluate the application to determine if it meets those requirements. If it does, production personnel accept responsibility for the application and maintain its performance according to established service level agreements (SLAs).
These basic steps are common in most application life cycles. However, because of the inherent complexity of Web applications, many IT organizations do not sufficiently address performance management throughout the application life cycle. Specifically, development, QA and testing, and production teams must review the following processes in each stage:
• Performance benchmarking in the development stage
• Performance validation in the QA and test stage
• Performance analysis in the production stage
The other critical factor required for a performance management strategy is developing a “true” holistic view of the Web application environment. Many internal and external factors affect Web application performance. These factors include network infrastructure, application design, and how well Web applications interact with disparate resources (HTTP servers, application servers, and databases) and their components (operation systems, CPUs, etc.). Issues with one or any combination of these factors can hamper application performance.
A decisive factor in any performance strategy is being able to view and measure the interaction between the application and all the resources and components it touches. This "holistic" view allows the engineering team to see everything that may affect performance and to discover the causes of performance problems that are unrelated to infrastructure (hardware) and application design issues. To further demonstrate the need for this view, consider a typical transaction: When a user executes a task from a browser, a request goes from the browser to the HTTP server and then on to the application server.
The application server calls additional resources including databases and backend systems before returning a response to the end user's browser. Depending on the application and the request, transactions happen from thousands to millions of times a day. By analyzing these transactions from end-to-end, IT personnel can identify specific areas where the transactions perform poorly during interactions with related application resources. Only through a holistic view of the Web application environment can development, QA and test, and production teams have the visibility they need to quickly identify the “true” root causes of performance slowdowns.
3. QUANTIFYING THE PERFORMANCE RESULTS: PERFORMANCE REFERENCE VALUES (PRV)
Every software release is accompanied by rigorous testing phase to not only validate new functionality, but also to ensure that existing routines are regressed properly.
But what about degradation in performance because of changes in the code ?
It is very important for projects to invest sufficient time and effort in putting together (re) usable framework to quantitatively measure application performance as often as possible and make it a mandatory part of release notes that accompanies every software release. This is where the performance reference value framework is applied.
Deriving the performance reference framework involves;
a) Defining the load model: The load model documents the 'day-in-the-life-of' kind of scenario from the system perspective. How many transactions, how often, how much think-time between transactions, number of users, ramp-up and ramp-down times etc.
b) Automation: Automated load testing like HP Load Runner are used to mimic the load model and generate sufficient system load. In order to make such load tests repeatable and self sufficient, it is essential that required test data be set up automatically by the test framework itself for every iteration.
c) Define a template that captures the transaction timings from load test and compares these against the expected SLA values. Rollup the timings across all the transactions and we arrive at the system performance metric.
d) In general it is a good idea to deploy probes to monitor the performance parameters of the underlying operating system stack - CPU, disk IO, paging, memory profile and the network traffic for the duration of the performance test to assist in diagnosis.
4. CONCLUSION
Our experience in addressing performance issues in projects converge to a few basic tenets:
a) Performance is a mindset, just like quality and should be an integral part of each phase of the SDLC
b) Architecture definition phase - distinguish between latency and through, define feasible SLAs for both; translate these into 'unconstrained' limits for the design team
c) Design Phase - Using the performance limits provided by the architect, split the module work into constituent tiers (separation of concerns) and estimate for each tier, based on quantum of work; adhere to those limits.
d) Construction phase - Test for performance often; use tools to automate the tests and analyse results.
e) Use of frameworks, plug-ins, tools and profilers to repeatedly measure performance.
f) Define a repeatable (automated) test framework, define and derive the (Performance Reference Value) PRV framework for every project
