Application performance testing: Modeling load testing scripts

by Alberto Saynes - originally posted on blog.quotiumtechnoloies.com 23rd July 2008
Automated Load testing is used to seek the answers to many different types of questions at different stages in the development and deployment of an application. Before a first deployment in production, these questions might be:
“What load will my application support for a given level of performance?”
“How will my application perform in time under nominal load?”
“How will my application react to spikes in load levels?”
“What changes do I need to make to reach a given level of performance at higher load levels?”
“What do I need to do to increase the performance of my application?”
“How does the new version perform as compared to the last one?”“How would the application react to loss of IT resources?”…
Once the application is in production, the questions are more pressing and the time to resolve performance issues is critical. The main questions at this stage are
“Why is the application not delivering the expected performances?”
“What needs to be done to quickly remedy performance issues in production?”
These two sets of questions are of course very much related. However, the application performance management tools currently available on the market do not make it easy to leverage the pre-production test runs and results when in production or to feedback production performance data to better design further load testing runs. A first level of response to this issue can be offered by using the same performance monitoring tool both in pre and post deployment in order to quickly identify and debug performance issues. A more comprehensive way to address this issue is to use integrated products to link the load tests executed pre-production with the application performance monitoring set in place in production. Very few companies offer this type of integrated solution. Whatever the load testing and performance monitoring tools, one key element allowing to leverage any load test in production is the simulation of real-life loads, a result of successful script Modeling.
All load testing tools provide a more or less elaborate script recording function. Recording scripts however is only the starting point. In order to simulate useful real life loads, each script must be modeled to include user-related profiles, variables, and actions. How modeling is supported by the script editor included in a load testing tool is a critically important factor in productivity and in the overall value of your load testing activity.
Modeling includes all script modification and customization that will lead to different user behavior based on which virtual user executes that script. It also makes it possible for a virtual user to react appropriately to dynamic application responses. Modeling techniques might include algorithms developed to reflect statistical behavior observed in production, Variables introduced to make user actions dependant on dynamic application responses or other techniques. However, for most comprehensive web applications, some modeling is actually necessary for the script to function at all. One of the trickiest and most time consuming scripts modeling activity involves dealing with Session Identifiers.
Session identifiers are used by the application to uniquely identify a client browser, while background (server-side) processes are used to associate the session identifier with a level of access. Thus, once a client has successfully been authenticated to the web application, the session identifiers can be used as a stored authentication voucher so that the client does not have to retype their login information with each page request. Manually dealing with session IDs can be a lengthy script edition task (even with powerful parsing and editing functions), and it is prone to errors.
Models: High end Load testing tools supports the concept of model in their script editor. Models are sets of script edition rules rules which can be created by the user and re-used anytime to automatically edit any scripts with a simple click. For the most common session ID modeling requirements, the editor should come loaded with pre-configured, ready to use models. These should include one click automated modeling support for application such as:
.NET applications (__VIEWSTATE, __EVENTARGUMENT,… variables),J2EE applications (jsessionid)SAP applications (sap-wd-cltwndid, sap-wd-appwndid variables)Siebel applications (SWEC, _sn, SWETS,… variables)Epiphany applications (SGloginRequest,… variables).
Etc…
Using these readily available models considerably speeds up the script modeling process, reduces the numbers of editing errors or omissions, and saves precious time to focus on application specific modeling so that the simulated load reflects real-life use of the application.