Many a times, web application performance aspect is ignored during development and it surfaces as a roadblock in scaling the application very late in the cycle when product starts losing revenue, users because of performance issues.
There have been numerous examples where companies have invested a lot in promotion of a product and when traffic actually starts hitting the product then issues like application crash, request time out surface and eventually companies lose a lot of revenue and users move to competitor products. Of course, everyone would not want to get their product trapped into such nightmares. So how do we tackle this problem ? Lets look into a methodical approach towards performance aspect of your web applications.
Quantify your requirements first
First step in performance assessment is to first set the quantified goals to achieve. Put across your goals to achieve in terms of -
- What is the end user response time goal ?
- What is going to be average load for your application?
- What is going to be peak load (users/hits per second/min)?
- Duration of peak load ??
- Threshold for max CPU usage at peak load ?
- Threshold for max memory usage at peak load ?
Start early -Agile approach
Often performance testing is put as a last item on the plan just before product release. This is definitely a wrong way to do. Agile principles are equally applicable for performance testing/optimization as well i.e. Start early > Measure performance against set goals > incorporate the changes > Measure performance again. Design your application for performance and scalability. Include performance measurement/optimization iterations right from beginning of the development cycle.
Is your performance script mimicking real life scenario ?
In real life scenarios at peak load different users are following different action flows, also there is wait time involved for each user input screen. Validate thoroughly if your test script is close to real life scenarios. Analyse what are different user action flows involved in real life and distribute the generated load through various user action flows in performance test.
Another aspect of it is if you have production like data in quality and quantity. Many a times generating load from one machine doesn't really generate the load because of IP checks in AUT.
Check if your test script request header parameters are externalised so as to manage different header values through an external CSV to generate real time scenarios. Make sure your scenarios include read, insert, update operations on database.
Is your performance test infra like production ?
This is really the crux of performance measurement. There is no point in running performance tests with different infrastructure than production. Of course, you don't need the scale of production infra but the configurations should be same. You should look at following aspects of test infrastructure and make sure they resemble production infrastructure -
Server Infrastructure: Number of CPU, cores, memory
Network Infrastructure: Network bandwidth
Software Configurations: This can vary as per your AUT (application under test). Make sure OS, web server, load balancer and any other softwares that are applicable for your application have same version, configurations like in production
Database: Data quality and size
Load injector: Keep your load injector machines to be different than the test server. Also, every client load injector will have a max limit to generate number of concurrent requests based on which tool you are using. So distribute your client load injectors as per your maximum load requirements.
Backend Jobs: In real life scenarios, apart from fronted http requests there are lot of backend activities performed by various backend jobs. Make sure your test environment also has this setup ready and running.
Monitoring Tools : Make sure you have all app, DB server monitoring tools setup
Which types of performance tests to conduct ?
Performance testing is a broad term. lets look at what all types of tests are covered under this -
Load Test: Conduct these iterative tests with different load values well below the expected goal and study pattern for response times, throughut, CPU usage, memory consumption, server logs During initial load tests application you will observe performance issues such as concurrency issues, functional errors under load conditions, high response times, high CPU/memory usage, Incorporate the changes one at a time and re-run the tests and see the pattern.
Capacity Test: While running iterative load tests you will reach to point where throughput is at its maximum and will not go beyond with subsequent increase in load. This is the maximum number of transactions per second your server can handle. Also check what is the corresponding response time values at this throughput.
This test will also give you what is the maximum load values corresponding to response time goals. Results from this test are basis to do capacity planning exercise to plan additional resources as business/users/transactions grow.
Soak / Endurance Test: In real life applications are running 24 x 7. During soak test you run load tests for longer periods (24 -48 hrs) and check for issues like memory leak.
Stress Test: During stress test load your application beyond its capacity to see if it negatively impacts your system, corrupts data. Check if system can be restored back at such conditions after reducing the load.
Overall, performance testing done right way can save you from the nightmares discussed at the start of this blog.
