Performance Engineering – Life Cycle

• Development – Code Optimization

  • Along with development tasks by development team, performance team can contribute towards Code Optimization methods[How much ever to the extent possible] like
    • Check if redundant code exists, avoid it
    • Check if the existing code is utilizing minimum resources [DB, File System, Threads, etc]
    • Code Review – Leverage static code analysis tools [SonarQube, etc] to ensure existing code base/repository is meeting coding standards
    • Check if any code optimization can be made possible like Caching – Redis, Reducing back end DB calls – Stored procedures, etc

• Production Deployment

  • While development team is working on deploying the changes to Production Environment, the Performance Engineer have to think of monitoring and capacity planning
    • Thus the performance engineer will have the leverage towards forecasting the production problems
    • Plan for capacity of the underlying infrastructure
    • Analyze the infra metrics(CPU and Memory Utilization, etc) and bottlenecks across various layers of application

• Performance Testing / Tuning

• • Ensure to cover various performance test kinds – Load Test, Stress Test, Endurance Test, Scalability Test, Volume Test
    • Load Test – Testing the application with decided virtual users with expected concurrency
      • How to decide on this expected concurrency for an existing application?
        • Leverage your project’s observability platforms like Coralogix, New Relic, Splunk, etc and calculate the daily, weekly, monthly metrics and arrive at an understanding to proceed further

• How to decide on this expected concurrency for a new application?
  • We have to baseline the metrics like response time, transactions/second with single user and calculate the metrics /hour, /day, /week, /month etc
  • Also, we will discuss, review these results with project’s stake holders and arrive at expected concurrency
    • Load Testing focuses on arriving at (x – number of expected) users per (y – duration of performance run) time
• Stress Test
  • Test the AUT for checking the break point (Until which point the application is performing well)
    • Eg: Testing the back-end APIs of the AUT until a point where we get Server Errors (500, 503, etc
• Endurance Test (a.k.a Soak Test)
  • To test the AUT by injecting x users for a longer period of time to check the memory leak
  • General time duration for Endurance test is approximately 4 hours
• Scalability Test
  • Testing the application with the infrastructure that’s available at hand/currently using infrastructure for a specified time, predicting a future load
  • The objective of this test is to understand if the current infrastructure can handle future
• load Volume Test
  • Volume test stresses more on testing those specific application scenarios having more DB(Database – SQL/NO-SQL) interactions
• It is expected to work on all these type of tests, and we might land up on testing a few as per project timelines, limitations, requirements

• Arriving at performance workload

• Use Little’s Law
  • Little’s Law defines as
    • Number of concurrent users a.k.a Concurrency = ( Transactions/Sec a.k.a Throughput ) * ( Response Time + Think Time + Pacing )
      • Pacing = Duration between various iterations
      • All the Transactions/Sec a.k.a Throughput ) * ( Response Time + Think Time + Pacing are having seconds as their unit of measure
    • Do not arrive at a random user concurrency, rather applying Little’s Law is suggested.
• Simulate a production like scenario
  • Analyze the user scenarios and arrive at an understanding on which scenarios contribute to maximum load, average load, and less load, and accordingly run the performance runs to simulate a production scenario
• Baseline/Benchmark the report
  • Baseline

• • • Running the performance script with a single user/desired user percentage, and multiply as per the desired outcome.
    • If we happen to arrive at a particular number for a previous application release, we will use that number as a baseline for the upcoming releases
• Benchmark
  • • To compare the existing number with that of the industry standard that’s been performing well
  • Performance Engineer have to focus on the above mentioned value adds and leverage the benefit towards getting desired results in Performance Testing

-By  Saravanan & Sai Krishna