Now, if you are proficient in LoadRunner, you may miss out on the details of how to go creating the start-stop transaction for the GUI Vuser script as the details are actually found in the QTP User Manual under the section, “Measuring Transaction” of HP Quick Test Professional User Guide – Volume 2 instead of LoadRunner manual.  In anyway, this is possible and only achievable via amending the scripts in QTP because Vugen will not be able open (read) QTP scripts.

Two ways you can insert a transaction.

• Via Keyword View – You can use Start Transaction icon > Insert Transaction at the step that you want the transaction to start measuring.   Subsequently, you will use Stop Transaction icon to stop the measurement.
• Via Expert View – You can use Services.StartTransaction “Transaction Name” and Services.EndTransaction “Transaction Name” to encapsulate where the start and end measurement.  “Transaction Name” is the name you give to defined for the transaction and this will appear when you run the GUI Vuser script in LoadRunner.

With the above information, you should be slightly more familiar with Quick Test Professional (QTP) integrating with LoadRunner.  However, again there may be more things that need to be considered and I may have left out.  Do feel free to feedback and experiences and anything that I missed out when using QTP in load testing!

In order to circumvent that, we use web_get_int_property API to retrieve the file size.  This file size will then be used to make comparison with the actual known file size on the server.  For usage of web_get_int_property, you can refer to the Function Reference available in Vugen.

On a brief overview, place the web_get_int_property APT after the request (web_url, web_custom_request, etc.) made for the file (PDF/excel).  I’ve extracted examples from LoadRunner Yahoo Groups and list them below for your convenience.

Example 1:

lr_message(“%ld”,web_get_int_property(HTTP_INFO_DOWNLOAD_SIZE));

web_get_int_property(HTTP_INFO_DOWNLOAD_SIZE);

web_get_int_property(HTTP_INFO_DOWNLOAD_TIME);

Note, HTTP_INFO_DOWNLOAD_SIZE does not give the actual size of PDF file.  This HTTP_INFO_DOWNLOAD_SIZE gets the body bytes, header bytes, and chunk bytes.  Therefore, you may need to fine tune the script to determine a range value of the PDF file size due to the header and chunk bytes.

Example 2:

float fFileDownloadSize, fFileDownloadTime, fFileDownloadRate;

funcFileDownload()
{
fFileDownloadSize = (web_get_int_property(HTTP_INFO_DOWNLOAD_SIZE)/1024.);
//in kilobytes
fFileDownloadTime = (web_get_int_property(HTTP_INFO_DOWNLOAD_TIME)/1000.);
//in seconds
fFileDownloadRate = fFileDownloadSize/fFileDownloadTime; //in KB/s

lr_output_message(“Size of download was %.0f kilobytes; Time of download was %.3f seconds”, FileDownloadSize, fFileDownloadTime);

lr_output_message(“Rate of download was %.2f KB/sec”, fFileDownloadRate);

return 0;
}

Example 3:

long DSize=0;

float DTime=0;

DSize = web_get_int_property(HTTP_INFO_DOWNLOAD_SIZE);

lr_output_message(“DSize is: %.2ld Bytes”, DSize);

lr_output_message(“File Download size is: %.2ld KB”, DSize /1024);

DTime = web_get_int_property(HTTP_INFO_DOWNLOAD_TIME);

lr_output_message(“File Download Time is:%.2f Seconds”, DTime / 1000);

web_reg_save_param(“p_EmpID”,
“LB=Emp_ID=”,
“RB=\”",
“Ord=ALL”,
“RelFrameId=1″,
“Search=Body”,
“IgnoreRedirections=Yes”,
LAST);

This is familiar coding where p_EmpID will be captured with LB of EMP_ID= and RB of “.  However, another parameter to note in web_reg_save_param is the ORD, or Ordinal.  This specifies the locaiton of the value to capture if multiple occurrences of LB and RB exists.  By default, the value is ORD=ALL which meant that all occurrences will be captured.  When all occurances are captured, they are stored in an array.  The total number of values captured can be accessed by placing a _count suffix after the parameter name.  Example (note, Total_Employees have to be defined as an integer in the script):

Total_Employees=atoi(atoi(lr_eval_string(“{p_EmpID_count}”­));

While to access a specified value in the array, you will put an index after the parameter in _{index} format.  Example illustrates reading the 2nd Employee ID in the array:

Current_EmployeeID=atoi(lr_eval_string(“{p_Emp_ID_2}”­));

Of course, these are just methods to read the values extracted for your scripting work.  Hopefully, you will find it easier when you are performing scripting work.

NOTE (21 Oct 2008):  Corrections to the default value of the Ordinal parameter.  It should be ORD=1, meaning the first occurence, instead of ORD=ALL.

• Parameter substitution
• Advance Trace
• Data Returned by Server

By doing this, there will be a tremendous amount of logging data being captured in the Replay Log. And sometimes, it’s overwhelming and redundant… And at times, the error could just be reduced to a small area of the script and you to go through the entire script to reach the log entry that is useful to you. Or you have to spend ineffective time waiting for the entire script to complete while it builds the big chunk of logging data during replay.

Let’s make things a lot more simpler… we just want to view the data when the error occurs on certain API calls and reduce the amount of data generated to the Replay Log. How do we do it? We can use the lr_set_debug_message to display only a certain portion of the log generated. What lr_set_debug_message does is to set the message level for the script execution during runtime.

Place the lr_set_debug_message before the codes that you want the replay log to receive and close it again as per your requirement. The syntax is as followed and more information can be consulted in the Function Reference.

Action()
{

// Turn on Extended Log logging for “Data returned by server”, “Parameter substitution” and “Advanced Trace”

lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG | LR_MSG_CLASS_RESULT_DATA | LR_MSG_CLASS_PARAMETERS | LR_MSG_CLASS_FULL_TRACE,LR_SWITCH_ON);

/*

…. Actions …

*/

// Turning off the Extended Log for all settings

lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG | LR_MSG_CLASS_RESULT_DATA | LR_MSG_CLASS_PARAMETERS | LR_MSG_CLASS_FULL_TRACE,LR_SWITCH_OFF);

}

As you can see from the above example, it is possible to mix and match the combinations of the message_level (i.e. LR_MSG_EXTENDED_LOG) with other message_levels in the API to suit your needs. Below is the relation of the message_level with the actual settings found from the GUI itself.

The fact is that it doesn’t really matter the type of language that was used to developed the application, but rather the type of communication method or protocol that the application is talking to the server. Previously, in “What’s LoadRunner?”, we mentioned that the tool captures network traffic while recording which is the core understanding that we must align when using this tool.

For example, an application can be developed using .NET 2.0 framework, is window-based (Win32). This application can be part of a N-Tier architecture that utilizes HTTP or HTTPS to communicate to the middle-tiers or a 2-Tier architecture that talks to the database directly using ODBC, ADO or JDBC-ODBC.

Similarly, an application can be developed using Java, but it talks to the middle-tier using RMI-Java or HTTP, or to its database using JDBC.

Despite the language or the type of of Applications (Java or Win32, etc.), the Load Tester must understand the communication method in order to determine the protocol to be used. This is done by consulting the development team of the application (which usually the Load Tester do not have such knowledge).

To understand the protocol used by the application (client to server), you can do the following.

1. The easiest way, check with the application team or vendor, particularly the software architects and the developers. They should be able to provide such information. If they don’t, it ’s time to doubt the experiences of the application team.

2. Use WireShark Network Analyzer to sniff the traffic communication when the application is running. More details of the usage can be found in the provider’s site. You should be able to see the protocols under the protocol column after you start capturing the traffic.

3. Use netstat -a to determine the protocol and port number. For example, the protocol is TCP and port number is 80, it could signifies HTTP. The caveat for this is that netstat -a only display protocol in IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6 (/? help for more information), which means you may need to guess the protocol according to the protocol (TCP) and port number.

4. Use Winsock protocol to determine the protocol via the data files. Winsock captures all traffic of any type at the socket level and writes it to the data file. From the data file, you will then find signatures of the protocol such as HTTP requests and responses in the context of HTTP.

Hopefully this methods are sufficient for you to determine the protocol used. Feel free to comment if you have a better method.

Mercury/HP Support have provided some information on this particular topic in Document ID 3803 – Nothing gets recorded while performing some client side activity and Document ID 42319 – VuGen is not replaying the rendering of an Excel file in the browser’s MS Excel plug-in. In both articles, it just merely describes what is client side activity and it cannot be recorded. (Take note that you required a valid login to the support website to access the article.)

At the release of LR 8.1 FP3, a new protocol called Web (Click & Script) was introduced. Document ID 48261 – New Features/Enhancements for the Web Click and Script protocol in LoadRunner 8.1 Feature Pack 4 provides more details in it as an enhanced released of FP4. This protocol “promises” that the scripting will be make easy and it will resolve some of the client-side activities such as Javascripts. However, to my experience, I wasn’t successful in using it (or maybe I missed out some steps concerning this new protocol)… anyway… you can give it a try in recording those web applications with Javascripts/AJAX or similar components embedded into the web application (if you have intentions in recording the client-side activities). I would be more concerned with actual load been generated to the SUT and will use the conventional Web (HTTP/HTML). Similarly, there is an AJAX protocol that was introduced in LR 9 to record AJAX applications.

Having the concept in mind, I would like to go a little further with the following example.

For activities such as, opening of file, editing in Excel sheet, or bat files performing copying operations are considered to be client-side activities. Think about it, do they generate any network traffic (unless you the activities really have a network call to a remote server)?

Another example is that if a web application allows opening of files such as documents over the browser (e.g. Sharepoint). The underlying mechanism for the file opening operation still requires a client installation of the program (e.g. MS Word), and subsequent activities are done locally on the client machine even though it exist in a browser. This of course is also considered as a client-side activity.

So, before recording the application, please ensure that you know the functionality of the Business Process that you are recording and determine if it is a client or server activity. This will greatly reduce the unneccessary effort in scripting and later realizing that it is client activity. If it is a client activity, a no-go, wrong tool for the job! It served no purpose of the tool to conduct non-performance tests. Consider other tools such as Quick Test Professional or Silk Test for functional testing client-activities.

1. Tell your clients/users that the application failed to respond in the 120 secs time frame

Well, straight-forward. This is because it failed the 120 secs benchmark, an equivalent of 2 mins. Imagine a normal application not responding within 2 minutes is serious where we are anticipating an average respond time of 10 secs!. However, take note that if your application can respond more than 120 sec, then consider the next suggestion.

(Source: Jakob Nielsen, Response Times: The Three Important Limits)

2. Set the Step Download Timeout to 999 secs

This was brought out in the LoadRunner Yahoo Group. Why 999 secs? The benefit of doing this is that you are able to determine the response time from the application in the 999 seconds limit without allowing it to fail. This is good when you want to measure the actual timing without defining a benchmark.

3. Limit the Step Download Timeout to the expected response time

For this, discuss with your clients/users about the requirements for expected response time. Once you gotten the information, configure the Step Download Timeout accordingly to the expected response time. In this way, you are able to tell if the application pass or fail immediately against the expected response time. But if your clients/users wants to know the actual time taken, then it would be advisable to follow the suggestion in point [2].

Hope this will help you have a better understanding on the impact when you configured the Step Download Timeout and assist you in your followup actions.

HTML-mode

HTML-mode recording is the default and recommended recording mode. It records HTML action in the context of the current Web page (which means everything you see on the web page will be recorded in a single function). However, having mentioned the above, it can be configured to your needs on the level of resources you want to record (Refer to Vugen User Guide, “Setting Recording Options for Web Vusers” for more information).

(Source: LoadRunner Yahoo Group)

The advantage of this mode is that it generates a script that is intuitive to the reader in terms of what is the form requesting (in a form of entire web page). Readers of the scripts will then be able to recognize each “logical” requests/call made to the server, making amendments to the script easily.

URL-mode

The URL-mode option instructs VuGen to record all requests and resources from the server. It automatically records every HTTP resource as URL steps. This recording mode captures even non-HTML applications such as applets and non-browser applications.

(Source: LoadRunner Yahoo Group)

The advantage of this mode is that it generates a script that has all known resources downloaded for your viewing. This works good with non-HTML applications such as applets and non-browser applications (e.g. Win32 executables). But having everything together creates another problem of overwhelming low-level information and making the script unintuitive.

When there are unrecognizable requests made to the server in Web (HTTP/HTML) protocol, they are recorded as web_custom_request. However, in URL-mode, this can be selected to allow recording to default to web_custom_request.

GUI-mode

This is introduced with Web (Click & Script) protocol. The GUI-mode option instructs VuGen to record all editable fields in an object or non-browser applications. What it does is to detect the fields that have been edited and generate the scripts accordingly. The concept is similar to functional testing when objects are detected at the GUI-level. When reading the script, it allows easier reading as the script is based on the GUI presented to the real user.

Different modes of recording in LoadRunner

Hope that helps give an overview of what and how you should choose in recording the Web (HTTP/HTML) protocol. My recommendation is to stick with the defaults unless you are facing issues with recording and if the application you are working with is not of browser natural.

1. Think Time

2. Action Blocks

3. Pacing

4. Iteration

Configurables for user behavior in Controller are as followed:

5. Ramp-up and Ramp-down rate

6. Rendezvous

We will go through the details of the configuration in future posts. Do stay tuned to it. For the purpose of the discussion, we will relate to a web application with form submission ability.

[1] Think Time

Think Time is a value that emulates the time the real user is thinking, performing an action or doing nothing at all. This value is being recorded as it is during the recording process.

Why do we need Think Time? Think time represent the real time used by the user perform their daily task. Note that when Vugen records, it records network traffic. During replay, it merely runs the script to re-generate network traffic. In this way, if think time is not included in the replay, the script will run without any delay (consideration of the time needed by users to think, act and wait) which will replay as a more like a robot than human.

E.g.

You want to emulate the user typing and reading the form before the submission which may take approximately 20secs.

[2] Action Blocks

Action Blocks allow different activities to be performed either concurrently or mutually exclusively. This is useful when you define the virtual user to be more humane as it has more “options/choices” to execute its activity.

E.g

You want to emulate the user to perform submission for 7 times. After the 7th submission, you want the user to review the submitted forms.

[3] Pacing

Pacing is the time interval between Action Blocks. This may be needed when you want to have a delay between the actions you’ve created, creating a more realistic replay. As mentioned in Think Time, if no delay is involved, the script will replay excatly like a robot.

E.g.
You want to emulate the user having delays from the 1st form submission to the Nth form submission as the user maybe running some other errands between each submissions. This delay is then configured to the estimated errand time.

[4] Iteration

Iteration allows the action block to be repeated per script. This is useful when the real user accessing the application maybe performing a particular action more than once.

E.g.
You want to emulate the user performing same submissions for 20 times.

[5] Ramp up and Ramp-down Rate

This is the rate at which you are emulating the users to access the application. In a real world scenario, users will access the system at different timing of the day. As such, ramp-up rate helps to emulate such behavior. This is the same as for ramp-down where you configure the rate the virtual users to exit the application.

E.g.
You want to emulate the users accessing the application at 9am, 9:15am, 9:30am, 9:45am and 10am at a rate of 5 users in each 15min interval.

[6] Rendezvous

When you want to emulate a certain amount of users accessing the application at the same time, Rendezvous point becomes useful in consolidating the users to a certain time and releasing them accordingly to your configuration.

E.g.
You want to emulate 10 users reviewing the submitted form at the same time after submission at the same time. In Vugen, you define the point in the script where the virtual users will wait for 10 users to arrive at the same point before continuing the business process.

1. Introduction

Before we start choosing Java-related protocols to perform recording, you will need to understand the protocol that the Java application is using to communicate with the server. It maybe the case where the Java application is communicating via HTTP rather than RMI-Java, etc… If you have identified that the application is communicating with a Java related protocol, you can safely proceed to choose the relevant Java protocol.

For Java-related protocol, the recording works in the same way as .NET and COM/DCOM protocol. All of them share the same characteristics but I will specify to just Java and only Java recording. Pure Java scripting will be excluded in this article.

Unlike .NET and COM/DCOM, Vugen provides an interface to manage and filter the classes and methods via the GUI which is very convenient to the user. Hopefully, Mercury/HP may consider that in future.

2. Classes and Methods

You will need the knowledge of the classes and methods prior recording; and usually this information is held by the developers. The need to know the classes and methods is crucial because, LoadRunner (Vugen) implements a hooking mechanism to hook the traffic on the classes.

If you do not know what classes are needed for the load test, and allow LoadRunner to capture all traffic on the classes, you may result in excessive capturing such as GUI clicks or client activities. On the other hand, if you did not specify the actual classes involve in the load test, you may miss out on the real class being used.

The above mention is based on the default Java hooking mechanism that LoadRunner implements. But if you required to have additional classess you need to record, you will need to configure the hooking mechanism that will be covered in subsequent post. This is also the reason the knowledge of the classes and methods come in important.

3. JDK and JRE

Other than the knowledge of the classess and method, you will need to know the JDK of the application. By default, Sun Microsystems JDK (SDK) works with LoadRunner.

There will be scenarios that your application is not using te Sun JDK such as IBM JDK. If that is the case, my advise is to check with Mercury/HP on the compatibility level and this will save you lots of effort. In my experience, usually they are not as fully supported as compared to Sun JDK.

The minimum supported JDK is JDK 1.3 for LoadRunner 8.1 as of this writing. Take note that the recording is still very dependant on the JDK version installed. That is, if your application is JDK 1.6, you will have to install this version on the recording machine.

Lastly, JRE is insufficient for the recording to be successful. Ensure that JDK is installed.

4. Recording-specified

LoadRunner Vugen implements an API that hooks into the selected classes and record the traffic. Therefore, as pointed earlier, knowing the correct classes to hook is crucial.

With the hooking in place, GUI classes or client-side activities maybe recorded via the hook. However, this is not recommended as it does not contribute to the load generation towards the server. I will share with you the recording details in another article. Do stay tuned for it.

5. Scenario Execution

Prior the scenario execution in the Controller, ensure that JDK have be installed on the Load Generators. The scripts sent (refer to the article,“4 points to note for Scenario Execution” for more information) are Java scripts, and require JVM to run.

6.Documentations

If you like to know more information from the official provider, you can refer to the Vugen User Guide that is provided in each installation of LoadRunner in PDF format. Specifically the following chapters:

1. All chapters in Part II: Working with Java Language Protocols
2. Chapter 18: Developing Corba-Java Vuser Script
3. Chapter 19: Developing RMI-Java Vuser Scripts.

7. Samples

Also, if you like to get a feel of working with Java protocol, I would recommend using the sample example provided with every installation of LoadRunner. It will at least get you understand what will happened and the expected output when recording Java language applications.

That comes to the end of the introduction of the workings of Java language protocol in LoadRunner, things to watch out and additional resources to pertaining to the topic. Do take note that Java is not as straight-forward as Web(HTTP/HTML) and therefore give it additional attention when working on such load testing projects.