Hybrid performance testing using Noise Generation in LoadRunner 12.02

In Real world scenario, there will be 20-30 % of idle users(may be higher/lower for some apps) and we also include them while taking the volumetrics but those idle users majorly access the website and then remain idle or closes the session by doing nothing and we call those as NOISE.

With LoadRunner 12.0 HP has provided us the option to generate NOISE along side normal testing and we shall see the purpose of that noise and how we can build a hybrid test scenario using Noise Generation option in LoadRunner. With that we have 2 approaches to web performance testing...

1. Create relatively complex tests with transactions, complicated flows, parameterization, checkpoints etc. Such tests, of course, require a complex script and can produce large amounts of interesting data.
2. Create a heavy load on the server by having the same URL accessed simultaneously by a large number of real or virtual users utilizing the power of load testing. The test typically consists of very few lines of code, and won’t be able to produce any sophisticated data. It can only determine the response times and whether the server has crashed or not. We call this “noise generation”, not out of disrespect, but to illustrate that such a test would create a massive and not quite coherent load on the server application.

Traditionally HP LoadRunner has been providing the means for enabling the first approach, so that users can test complex business flows and perform a detailed analysis of the resulting data. However, in some cases it’s enough to execute such flows for a relatively small fraction of vusers, while the rest can just generate load on the server in order to simulate stress conditions for the more “sophisticated” vusers.

HP introduced the “Noise Generation” feature in LoadRunner for precisely this reason. It lets you implement a hybrid testing model:  run large amounts of reasonably-priced vusers, which will generate a ‘primitive’ load by accessing a single URL, and alongside them, a smaller number of ‘proper’ vusers, which will gather the ‘interesting’ data.

Here are the main characteristics of the ‘noise’ vusers:

1. They’re 10 times cheaper than the regular ones! If you purchase a license for, let’s say, 100 Web vusers, you’ll be able to run 100 regular vusers (as before), or 50 regular and 500 noise ones (which you’re getting for the price of 50 regular), or 10 regular and 900 noise – any combination, as long as the amount of full-scale vusers plus the amount of the noise vusers divided by 10 doesn’t exceed the number of purchased licenses. (Note:- With trail version HP is giving license to 50 Vusers and that means 500 noise user load by default)
2. No VuGen scripting is needed in order to build a noise vuser script. Just input the number of vusers and the URL you’d like to put under stress, and LoadRunner will take care of everything else behind the scenes.
3. A noise vuser works by simply sending an HTTP GET request to the specified URL, once per test iteration.
4. Although noise vusers can run alongside a script based on any protocol, the main goal of this feature is to support Web-based protocols, such as Web HTTP, Mobile HTTP, Flex, SAP Web etc. Nevertheless, if your application under test has a Web interface of any sort, you can apply a load to it using the Noise Generation feature, even if the main testing is being done using a different technology.

 So, how does this feature work? Very simply! As mentioned above, no recording or VuGen scripting is needed. When you’re defining your testing scenario in the Controller, just press the familiar “Add group” button, and you’ll see the new “Noise Generator” option:

Select the ‘Use a Noise Generator’ checkbox, and type the URL, which will be the target of the noise generation.  Select the Load Generator machine as usual (unless you’re working in the percentage mode), the number of vusers (remember that you can use 10 of these vusers for the same price as a regular vuser) and the group name (although you don’t have to do the latter, the Controller will auto-generate it based on the URL’s domain):

Note that the “noise_” prefix is automatically added to the noise group names, in order to distinguish them.

The ‘Details’ dialog will reflect the fact that it’s a noise group we’re talking about in the script type and the ’View Script’ button will be disabled:

Since the “noise” script is rather primitive, there’s not much you can do in the way of configuring it. However, one thing is particularly important. If you want to get meaningful data from the script execution, make sure that either the “action as a transaction” or the “step as a transaction” option (which is the same thing in this case, since the script’s main action contains exactly one step) is turned on in the Run-time settings. That way you’ll be able to obtain accurate measurements at the end of the script run:

And that’s it! You’re ready to run your hybrid Web+noise test, and the ‘noise’ groups will run just like any other.