Introduction

Performance test run

Plan / Design

Before executing a load & performance test it is important to have objectives. These objectives should relate to the performance requirements of the target application such as ‘the site must be able to withstand X users during for a period of Y while maintaining a transaction rate of Z’.

While it is not always the case that performance requirements are written out formally, at least some level of activity the test should generate should be established before execution. It is very easy with something as powerful as AgileLoad to quickly bring the target of the test down or to significantly reduce performance by overloading the target application. The object of a load & performance test is not to 'break' the application but to evaluate its performance under realistic load.

The target system should have been identified in the early stages and it is important to consider the relative size and capability of the system when contrasted to the live system, of course the development system will not always scale to the capability of the test system and the test system may not be a direct representation of the live system so expectation should vary accordingly.

Testing against the development system can help by enabling an understanding of application performance early in the project lifecycle and helps build performance in. If the scripts used for this stage of testing are to be reused then they must be directed toward the new target application which could be the test or live system.

Before executing a test it is vital to make sure that you have the correct target as executing a load test against a live system at the wrong time could have a direct and disastrous business impact if live users are affected. Often in the case of running a test against a live system, out of hours tests are preferred so that disruption is kept to a minimum.

Build

If a plan has already been specified then the build should just be a case of plugging numbers into AgielLoad Center’s Job parameters. If not, the building up of scenarios in AgileLoad will require that numbers of users are assigned to scenarios, numbers of iterations are specified, ramp up rates are set and other parameters (if required) such as running orders for scripts, specification of browser types to emulate, bandwidth rates to emulate and service level agreements are set.

An important part of building the test is to specify any monitors that are required. Therefore it’s necessary (if monitoring is planned) that all infrastructure touched by the test is identified and included as a monitoring target in AgileLoad.

Execute

Execution is a simple click of a button once the preparation above is complete. During execution it will be possible in AgileLoad to evaluate how the test is running and see the performance metrics relating to the application under test. Also it is possible to adjust the load up or down, if deemed necessary. Execution will be either stopped automatically (especially if running unattended in an out of hours scenario) or it will be stopped manually. At this point it’s probably already possible to give an initial appraisal of the application before the full analysis. Tuning adjustments to the application and infrastructure would be made at this point then the test would be run again. This forms an iterative approach until the application has been tuned.

Analysis

Analysis is discussed in the next section and shown here to highlight the iterative approach to performance testing.

Next Capturing a Job with Agileload Starter
Getting started > Introduction
Print this page  -  Go to top of page