Correlation in Load Testing

09. July 2012 · 2 comments · Categories: Load Testing, Scripting

Correlation is used to account for dynamic values in load testing. Many web applications have dynamic data that changes every time the user runs that web application. Web applications often need to track users’ interactions as they navigate through their website while preserving their state between navigations. Session ids for example are used by server engines such as ASP, ASP.NET, JSP and PHP to manage sessions. These session ids will change each time the page is loaded.

Users typically use recording mechanisms to record their scripts. In some cases, they will not be able to replay the recorded script without modifications. It doesn’t matter how good or sophisticated the load testing tool is. It is impossible to create a script recorder that can accurately record and replay every scenario. This should not be taken to mean that you should not use the recording capabilities of these load testing tools since recording scripts is a great way to create a starting script. This considerably reduces the amount of work needed to create a working script.

Here is an example to illustrate correlation and dynamic data. Consider the web page below.

<html>
<body>
<a href=”/784768″>
</body>
</html>

The link (A tag) contains a href value that is dynamic (i.e. changes every time the page is loaded). The next time the page is loaded the HTML may look something like this

<html>
<body>
<a href=”/792187″>
</body>
</html>

If you attempt to record and replay this script, unless you modify the script it will fail. The href values of the link (‘a’ tag) are dynamic and need correlation to work correctly. The only way to make this script work is to edit it and dynamically extract the href value i.e. /784768, /792187, etc. and use that value to request the subsequent page.

But hey, you might say, what about all these load testing tools that record actual browser interactions. Their users don’t need to worry about correlation and dynamically changing data since they are replaying actual user interactions (in a manner similar to functional testing tools). The problem with these kinds of load testing tools is that they will have tough time running more that around 10 or so virtual users on one machine (despite the vendor’s claim that it can run 50 or more users)! These tools will instantiate actual running instances of a web browser. This means that they also load the huge footprint of a normal web browser to accomplish a task that typically only requires a small fraction of that functionality. it is thus easy to see why once you run more than 10 or so virtual users, the machine will be completely maxed out. In this case a 1000 virtual user load will require around 100 computers, which is excessive by any standards (ordinarily, you would be able to run 1000 virtual users on single computer).

Dynamic data in load testing requires correlation to enable load testing scripts to run accurately. It is important to keep this in mind when you use recording to generate a script. If the script is unable to replay accurately, there is a good chance that this is because dynamic data is involved. The way to address this is to use correlation techniques.

Share

Load Testing Activity Spikes

16. March 2012 · 3 comments · Categories: Load Testing, Scripting

In the real world, web traffic often occurs in localized spikes. Let’s assume that we are creating a load testing script for an insurance quote. The user logs into the system, makes some selections and then finally clicks a button to calculate the insurance quote. This can be modeled quite easily by recording a load testing script using the vPerformer Builder and then generating a large load of perhaps 500 concurrent virtual users. In this scenario even though all the load testing scripts are running concurrently, each script would not be performing the same step. In other words, one user could be logging in, another could be making a selection, a third one could be waiting, a fourth one could be obtaining the quote.

There are many situations, however, where a very large number of users are attempting the exact same task simultaneously. For example we could have a situation where a large number of users could be attempting to simultaneously obtain a quote. This would result in a significantly larger load on the server.

vPerformer can model this scenario using a capability called a sync point. A sync point makes virtual users wait during load test execution for a specified number of virtual users to arrive at a certain point in the script, so that they can perform a task simultaneously. A sync point placed in your script would ensure that a specified number of virtual users pause until they reach the same task. At that point they would all execute the tasks together.

SyncPoints can be added to your load testing scripts graphically or they can be inserted as a JavaScript function into your text scripts. To insert graphically select the menu item Edit > Insert Function. A function selection dialog box will pop up. Under Utility functions select “Sync Point” and click OK. A function parameters dialog will now pop up. Set the name and the number of virtual users and click OK. To insert into a text script, insert a line that looks something like ‘UtilSyncPoint(“mysyncpoint”, 500);’. This would insert a sync point called ‘mysyncpoint’ with 500 virtual users. This should be inserted just before the part that you wish to have simultaneously executed.

Sync points allow you to model a phenomenon in your scripts that often occurs in the real world. Sync point logic will not occur in a script unless it is specifically specified. Sync points can make your load testing scripts more realistic and are a valuable tool that should be used when needed.


Share