Performance 101 : The Basics

Everyone is talking about it. Everyone wants to know it. Everyone whats to do it. Everyone wants faster apps, faster responses, faster downloads. But the question is how does one get started with performance testing an application in the first place. This article is a place where all the basics are in one place.
This is not one of those in depth articles which confuses you all over the place. It is a hands on guide to how to start the whole process.
Hope you find it useful.

Requirement Document
This is probably one of the most important documents that is underscored for its role in the performance testing. Read, read and re-read this to identify which are the components that are really going to be important. Which are the APIs that should form part of your performance testing strategy.
I cannot elaborate enough the importance of understanding this document thoroughly.
Even if the developer tells you what is to be tested, read this document to be sure nothing is missing because, hey! every developer wants the software that he/she has developed to perform well. So you cannot really trust them a 100%.

Identify Workflows

After the components to be tested are narrowed down, get down to detailing out the step by step workflows that are important from a performance perspective. By this what I mean is, you may want to skip the workflows that are executed maybe once, like application boot, and focus on things like login or saving data to a database. It helps to have a end user perspective while doing this, so knowledge of the entire UI is a good to have. Think as a user, what is it that I would do and how would I use the system. Which are the points where waiting for a response (the wheel loading icon ..) is agonizing. Be sure to include those in your performance test plans.

Define the SLAs

For each of the workflows that are to be performance tested, define a response time that is acceptable. You may be given this by the product owner, but if not, its a good idea to set a realistic value for this. For example, if user is logging in, the login success/failure should return within 1 second.

Define the Load Patterns

This is important. For each of the workflows and SLAs that are identified from the earlier steps, define the maximum load that is expected. Typically this could be number of users logging in at a time or it could be the number of requests per second. It depends on the application. For some applications you may want to include endurance tests, especially for the long running applications. For some, reliability may be a concern. So get into a discussion with the product team to understand what are the important ones for the applications

Tools

Now , based on your analysis, you need to finalize on which tool can be used for running all the performance tests and load scenarios. Typically, a tool stack that does the following jobs is required —

• Capture CPU
• Capture Memory Statistics
• Capture Network Statistics
• Scripting for the Tests
• Analyze heap dumps

There are open source tools and paid ones. Which one to choose would be dependent on the budget, type of project etc. (more on tools in a later post)

Finally…

Once the scripts are ready, the final aspect is the performance testing environment. Remember, it must be an isolated environment where at a given point of time only the performance tests and the tuning steps are run. This is isolation is essential for getting reliable and stable numbers for your tests. The test environment configurations and hardware should mimic the production one as much as possible, preferably down to the last T. This ensures the numbers can be extrapolated to the application running in production.

There! You are all set to begin the performance measurement for your application.

Happy Perf Testing!