VUGen

Home
Get More Info
Company Information
Services
Types of Tests
Documentation
Technology
Resources
Feedback
Join

VUGen - As a protocol replay tool

Find out how we can help you use VuGen and LoadRunner as part of our consulting services.We use Virtual User Generator (VUGen) to record the protocol from a vast variety of user applications for playback in various types of load tests.  As VUGen is a protocol based testing tool, we can use a relatively small amount of load generation hardware to simulate a vast number of users for a load test.  Visit mercuryinteractive.com/products/loadrunner/ for detailed information on LoadRunner, of which VUGen is a component.

VUGen is also used as a scripting language for Topaz.  Visit mercuryinteractive.com/products/topaz/ for more information on Topaz.

The following diagram shows how a protocol level recording and playback tool, such as VUGen works.  Note that only the communications is captured and recorded for subsequent playback.  Events that do not generate communications such as moving the mouse, or editing data in a field on a web form are not recorded because those events do not interact with the system under test.

This is a how a protocol level tool, such as VUGen operates.

During a load test we need to run many virtual user sessions, and we do it by replaying the protocol that is described in a VUGen script under the control of a LoadRunner Controller.   A copy of the client application (a web browser in the case of  a web application) does not need to run for each session, as all of the protocol information is contained within the VUGen script.

The example below relates to an Internet Explorer session starting up and connecting to www.google.com.au and then performing a search on "Mercury Interactive".  As can be seen, protocol based tools such as VUGen records each of the interactions between the browser and the Google web site, including the setting of cookies and the transmission of the search request containing the text "Mercury Interactive".  The tool needs to do the following:

bullet Add Cookies that Google uses to each header.
bullet Make an HTTP request on the URL "www.google.com.au".
bullet Make HTTP requests for each of the GIFs on the page.
bullet Perform an HTTP GET on the URL "http://www.google.com.au/search" constructed with content to cause the web site to execute a search on the text "Mercury Interactive".

Each of the above steps can be seen in the screen print shown below.

Screen image of Virtual User Generator script.

The concept of 'protocol replay' is central to the way that Load testers are able to generate substantial load with minimal load generation hardware.  This is a direct contrast to the way that GUI based testing tools, such as WinRunner operate, as GUI based tools need to use an entire instance of the client software for each virtual user.   Refer to the page on WinRunner for more information on the way that GUI based testing tools can be used in the context of load testing.

The concept of protocol replay can be better understood by looking at other examples using different protocols.

COM/DCOM protocol example

LoadRunner comes with various sample applications, so that a tester can get some practice on a simple application before attempting to script a test for a complex application.  One such sample is the COM based 'flights' application. 

The following screen shows what the Virtual User Generator script looks like for a COM/DCOM protocol.  You can see from script example that this portion of code relates to the end of the login process and the start of the process to select a flight (because of the start and end transaction marks that I inserted).  You can also see the SQL statement showing that the list of flights relate to 'Denver to Los Angeles on Tuesday'.  For a realistic test, these values need to be paramatised so that the same SQL statement is not executed over and over again.  The script also needs to be correlated so that the values returned from such an SQL statements is able to be used later in the script.  For example, if the first flight from Denver to LA on Tuesday were selected when the script was recorded, that flight may have a flight number of 12345.  However, if the locations were changed from LA to New York then the first flight may have a number of 23456.  VUGen needs to know to send 23456 instead of 12345 in subsequent communications to the server, and this is achieved by correlation.

Virtual User Generator - VUGen - COM Script example

As can be seen from this example, some logic is required to replay the COM protocol, but much less processing power is required than the actual application that was recorded.  This means that a large number of such Virtual Users can be simulated with a single load generator computer.

Send mail to webmaster@loadtest.com.au with questions or comments about this web site.
Copyright 2004 RPM Solutions Pty Ltd - abn 64 007 217 941             Last modified: August 04, 2004   
The content on this web page represents and demonstrates the way that RPM Solutions Pty Ltd understands and conducts load testing engagements.
This page is not an instructional guide - and RPM Solutions Pty Ltd does not take responsibility for the use of the information provided herein.