Performance testing & tuning for any application is critical for a successful delivery but a lot of times it is either ignored in the estimates/plans and picked up when it’s already too late or in some cases simply ignored due to a lack of an existing performance testing & tuning approach. While there is no common solution to tune every application the same way, the approach to set up & execute the tests is fairly consistent. Here are 10 key steps towards defining your performance testing & tuning approach:

1. Capacity Model

• Define the capacity model that shows the current and expected traffic volumes for your application. The metrics can be:
• Avg & Peak HTTP Requests Per Day/Hour
• Avg & Peak User sessions Per Day/Hour
• Number of Unique Users
• Tests could be done with 2x, 3x, 5x load based on the test plan & goals
• These stats should be used to define avg & peak traffic volume (virtual concurrent users) & overall throughput expectations

2. Performance Testing Goals

• Page level response times (client side vs servers side)
• System up time
• External system integration benchmarks
• Response times for asynchronous jobs or processes if any

3. Environments

• Typical challenge – try to leverage the future production infrastructure to simulate LIVE scenario
• Else simulate a “similar scaled down” architecture
• The capacity model should be extrapolated based on the relative scale

4. Data Generation for Data “Noise”

• Can get overlooked at times. Data – static data in DB, # of users, images, files on file system etc should mirror a production “like” scale
• Bottlenecks may not surface due to lack of data on non Production environments
• Plan for data creation scripts upfront

5. Code Instrumentation & Performance Logging

• Critical for performance measurement – performance loggers within the code from the get go
• Part of your coding standards – identify methods for performance logger, typically at entry & exit points

6. Performance Data Collection Sheet

• Identify the different data points that will be captured during a performance test
• Could contain server stats, application level data and so on. Capture at different time stamps during the test
• Use data for post test analysis & review

7. Testing Tool Selection & set up

• A load testing tool best suited for your application – open source or licensed
• Use a separate server for the tool other than the application server
• Simulate realistic network latency between load generator & origin server to avoid skewed results

8. Document Performance Test Plan

• Number of test executions with respective duration and load generation stats
• Focus area for each test:
• Longevity test with avg load run for 2-3 days to identify memory leaks
• Peak load test to identify the application threshold

9. Test Monitoring

• Monitor the server stats & the application real time during the test – CPU, Load Avg, threads, response times etc.
• Don’t just depend only on post test data analysis
• Log your findings for post test analysis – avoid problem solving during the test

10.  Code & Server Configuration Tuning

• Now resolve the identified bottlenecks or performance issues
• Root cause could vary from a simple coding error to a complex hidden memory leak or a server configuration, the list can go on
• Use generated logs to narrow down problem areas
• Possible test & trial approach. Resist the temptation to make multiple changes at the same time – use a single elimination methodology

The approach here will not solve your performance issues but will help you take the right steps to identify the bottlenecks and provide enough data points to lead your analysis in the right direction.