Parameterize the object xpath in TruClient Protocol Loadrunner - JavaScript Based

Scenario:

1. Search a Company in the search field.
2. Click that Company from the search results.
3. Repeat Step 1 & 2 for different companies.

• I searched for a company PERFORG60.
• In the click step I found that the objects xpath had company name PERFORG60 and that is used to select that company.
• Now I need to make the above steps work for different companies that I input.
• Since the Company names are user inputs, I need to parameterize the Company name PERFORG60 in the xpath.

Steps:

1. Expand the Click Step --> Goto Objects --> JavaScript

2. Actual xpath generated in the step - evalXPath("//h3[text()=\"PERFORG60\"]");

3. Parameterized xpath to be replaced - evalXPath("//h3[text()=\""+ArgsContext.TC.getParam("P_OrgName")+"\"]");

where P_OrgName is the company name file parameter.

Now your script will click different company names which you input.

Parameterization in TruClient Protocol Loadrunner - JavaScript Based (Method 1 - TC.getParam)

Step 1 : Create a parameter under Parameters Dialog Box. I have created a File Parameter of name P_MPID. (Highlighted in RED)

Step 2 : Click the Develop Script button

Step 3 : Goto Tools --> Miscellaneous --> Evaluate JavaScript. Click and drag Evaluate JavaScript and place it above the step where the parameter P_MPID has to be passed. (Step Highlighted in BROWN - Last Image)

Step 4 : Fetch the parameters from P_MPID using TC.getParam function and assign it to the variable MPID. Follow the code in Arguments section. (Code Highlighted in RED)

Step 5 : Goto the step where the parameter P_MPID has to be passed and replace the original value with the variable MPID in Value field under Arguments section. (Highlighted in RED)

Step 6 : By default Value and Typing Intervals fields will be in Plain Text. Now click on the drop down arrow and select JavaScript <JS>. This has to be done because we are passing the parameter using JavaScript. (Highlighted in GREEN)

C Program (using strstr function) equivalent of web_reg_save_param in loadrunner.

I had a situtaion in which I was not able to retrieve the session id from the resposne using web_reg_save_param function. The session id was available in resposne header.
So what I did is, captured the entire response header and from that I retrieved the session id using the Left & Right boundary via C Program. Pls find the code below.

char *CStr; //variable in which the response header will be saved
char *LB = "SMSESSION="; //Left Boundary of Session ID
char *RB = "; path"; //Right Boundary of Session ID
char *CorrParam = NULL; //variable in which Session ID will be saved
char *start, *end;

web_save_header(RESPONSE, "Input"); //LR function to capture the response header

/* login request */
web_submit_data("login",

lr_output_message("# Response Header:\n %s", lr_eval_string("{Input}")); //Print the response header
 
    CStr = (char *)calloc(8000000,sizeof(char));
 
   strcpy(CStr, lr_eval_string(lr_eval_string("{Input}"))); //Save it to the C variable

    if ( start = (char *)strstr( CStr, LB ) ) //Finds the first occurance of LB in CStr
    {
        start += strlen( LB );
        if ( end = (char *)strstr( start, RB ) ) //Finds the first occurance of RB in CStr
        {
            CorrParam = ( char * )malloc( end - start + 1 );
            memcpy( CorrParam, start, end - start );
            CorrParam[end - start] = '\0';
        }
    }

    if ( CorrParam )
   
   // printf( "%s\n", CorrParam );
    lr_save_string(CorrParam,"CSMSESSIONID");
    lr_output_message("%s", lr_eval_string("{CSMSESSIONID}"));

    free( CorrParam );
 
    web_save_header(RESPONSE,"");

lr_save_float - C Program to convert Integer to Float in loadrunner

I have written a C program - user defined function to convert integer values to desired float decimal values in loadrunner.

Executing a client side session creating Java Script in loadrunner using web_js_run (web protocol)

In web applications unique user Session Id's are used for security reason. These Session ID's can be created either on the server side or on the client side. If they are created on the server side then we can correlate those session ID's in our loadrunner scripts. But in my case these Session ID's were created using Java Script in the client side (Browser). So these Java Scripts have to be executed in loadrunner to create the session id's and they have to be consumed in our script.

Lets see how we can do it.

When the application launch URL is executed it gets a response with the below Java Script embedded in it to create session id.

Java Script to create client side session id:

        function uuid() {
            var chars = '0123456789abcdef'.split('');

            var uuid = [], rnd = Math.random, r;
            uuid[8] = uuid[13] = uuid[18] = uuid[23] = '-';
            uuid[14] = '4'; // version 4

            for (var i = 0; i < 36; i++) {
                if (!uuid[i]) {
                    r = 0 | rnd() * 16;

                    uuid[i] = chars[(i == 19) ? (r & 0x3) | 0x8 : r & 0xf];
                }
            }

            return uuid.join('');
        }

• Copy this code in a notepad and save the file with extension '.js'. In my case I have saved the file as 'Cookie1.js'
• Place this file inside the loadrunner script where it need to be executed.
• In Vugen goto Design --> Insert in Script --> New Step --> Steps Toolbox --> Search & Select web_js_run. Below dialog box opens.

Under General Tab

• Select the Code option and call the function using its name. In my case it is uuid(). Since there are no arguments the function is blank.
• Enter a parameter name in Result parameter field to save the output of the Java Script. I have given 'output' as the parameter name. This is the parameter which has to be passed in the place of session id inside the script.

Under Sources Tab

• Click Add. In the resulting pop up select File and enter the file path. Since we have placed file directly inside the script folder, it is sufficient to mention only the file name. In my case is 'Cookie1.js'

• Thats it now click OK and the below web_js_run function will be generated in the script. When we run the script, session id will be created and saved in the parameter output, which can be seen in the replay log.

For loop to iterate a block of script in loadrunner

C Program:

int Max = 10; //no. of times for loop should run
int i =0; //initializing the loop

Action()
{

lr_start_transaction();
Web Request
lr_end_transaction();


for(i = 0; i<Max;i++) //For loop will run 10 times
{
lr_start_transaction(); //Block of the loadrunner script
Web Request
lr_end_transaction();
}

lr_start_transaction();
Web Request
lr_end_transaction();

return 0;
}

Loadrunner scripting for Rest API services - web_custom_request

In this post we will see how to script a Rest API call in load runner.

Rest API details:

URL : https://10.36.133.105:8104/belocc/v2/belea/dealer/B1234/rep/B1234/smsession/10/consignments?access_token=800004e-c7ca-400b-9004-48c8aef00000

Method Type: 
POST (Apart from POST other methods used in Rest API's are GET, PUT, PATCH & DELETE)

Mode: HTTP

Encoding Type: application/json

Request Body:
{
    "code":"0032906789",
    "entries":[
        {
            "CEntryNumber":"",
            "orderEntry":{
            "entryNumber":"1",
            "quantity":"2"
            }
        }
       
    ]
}

Convert the Request body to the below loadrunner format (i.e) place '\' before every '"'.

{\"code\":\"0032906789\",\"entries\":[{\"CEntryNumber\":\"\",\"orderEntry\":{\"entryNumber\":\"1\",\"quantity\":\"2\"}}]}

save the formatted request body in a character pointer.

char *JsonReqInit;

char *JsonReqFinal;

JsonReqInit = "{\"code\":\"0032906789\",\"entries\":[{\"CEntryNumber\":\"\",\"orderEntry\":{\"entryNumber\":\"1\",\"quantity\":\"2\"}}]}";   //save the string in a C variable.

lr_save_string(lr_eval_string(JsonReqInit),"JsonReqFinal");

Goto Design --> Insert in Script --> New Step

Then Steps Tool search window will open in the right pane, search for web_custom_request and open it.

Enter the details in each field and click ok. Below request will get generated in the script.

web_custom_request("Rest_API",
"URL=https://10.36.133.105:8104/belocc/v2/belea/dealer/B1234/rep/B1234/smsession/10/consignments?access_token=800004e-c7ca-400b-9004-48c8aef00000",
"Method=POST",
"TargetFrame=",
"Resource=0",
"Referer=",
"Mode=HTTP",
"EncType=application/json",
"Body={JsonReqFinal}",      //Pass the variable in the body of the web_custom_request.
LAST);

what is GC Suspension Time or GC Pause Time?

Garbage Collection:

When a Java application is running, it is creating new objects, but after a certain time, those objects will not be used, which will be considered as "garbage". Eventually, we'll start getting a lot of garbage, and memory will be used for objects which aren't being used anymore. If this keeps going on, at one point the Java Virtual Machine will run out of space to make new objects, leading to heap memory issues.

That's where the garbage collector steps in.

The garbage collector will look for objects which aren't being used anymore, and gets rid of them, freeing up the heap memory so other new objects can use that piece of memory. It is a form of automatic memory management.

Stop-the-world:

Stop-the-world will occur no matter which GC algorithm you choose. Stop-the-world means that the JVM is stopping the application from running to execute a GC. When stop-the-world occurs, every thread (including application threads) except for the threads needed for the GC will stop their tasks. The interrupted tasks will resume only after the GC task has completed.

The time for which the stop the world event occurs is called as the GC Suspension time or GC Pause time which has a direct impact on response time and throughput. GC tuning often means reducing this stop-the-world time.

The lesser the GC Suspension time better the response time and throughput of the application.

SSL protocol error when attempting to connect with host - Error in Loadrunner

Error Description:

When we run the script in vugen, sometimes we get the SSL error in loadrunner, "SSL protocol error when attempting to connect with host". This error will not be resolved even when we try to run the script with different SSL versions in web_set_socket function.

Solution:

We need to enable the winlnet replay in Run Time Settings.

RTS >> Internet Protocol >> Preferences >> Advanced >> Use Winlnet replay instead of Sockets (Windows only)

Once this option is enables script will run without any SSL issues.

C Program to get the correlation parameter value of the last ordinal in loadrunner

Below C program is to fetch the value of the last ordinal in the correlation. We will be fetching the value using the total count of values (Ordinal count) which by default will be saved in a variable CorrelationParameterName_count. This program is highly useful when the ordinal value is varying for each iteration.

C Program:

char lastval[30];

web_reg_save_param("AcctName", "LB=\",\"accountName\":\"", "RB=\"", "ORD=All", LAST);


web_url("IZ7_JP4EHCS0N0KRC0QGT3G5TT",
"URL=https://XXXXXXXXXXXXXXXXXX/?jsondata=%7B%22provider%22%3A%22%22%7D",
"Resource=0",
"RecContentType=text/html",
"Referer=https://XXXXXXXXXXXXXXXXX/?isam_post_url_client_company_name=PTY_Banking",
"Snapshot=t6.inf",
"Mode=HTML",
LAST);


sprintf (lastval, "{AcctName_%s}", lr_eval_string("{AcctName_count}"));

lr_save_string( lr_eval_string(lastval) ,"AcctName_Last");

lr_message("Account Name last value is %s", lr_eval_string("{AcctName_Last}"));

How to create a JMX monitor in HP Sitescope

In this post I will detail about creating a JMX monitor in HP Sitescope to monitor the JVM's performance during our performance tests.

1. First the JMX port should be opened in the server whose performance has to be monitored. This will be usually done by the server admins or the operations team.
2. Example - 10.100.11.230:9003. Here 10.100.11.230 is the ip address of the server to be monitored and 9003 is the JMX port.
3. In the Sitescope Create Group --> Rt.click Create Monitor --> Add JMX Monitor
4. Under General Settings tab provide a relevant name to the monitor. Example JMX_HostName.
5. Under JMX Monitor Settings tab paste the JMX String service:jmx:rmi:///jndi/rmi://10.100.11.230:9003/jmxrmi in the field JMX URL.
6. Under the same tab click Get Counter and select the appropriate counters.
7. Under Monitor Run Settings tab mention the frequency at which this monitor has to be run.
8. Under Threshold Settings tab mention the threshold conditions to indicate the health of the monitor.
9. Once everything is set, Click Verify & Save button at the lower right bottom.

Thats it, your JMX monitor is ready 

Application to calculate the Pacing time, Users & TPS for Performance Tests

Today I am going to share an application which can be used to calculate the Pacing Time on the click of a button. This makes our Work Load Model calculations simpler, easier and quicker.

Input for Pacing calculation will be Transactions Per Second, Users & Think Time (Not Mandatory).

We can also calculate Users & Transactions Per Second using the same calculator.

Calculator Link 

Function driven Framework for web (http/html) protocol in LoadRunner

Abstract:
The main objective of this paper is to reduce the effort involved in preparing loadrunner scripts using web (http/html) protocol and this is achieved by creating a Function driven framework. Say for example if we have hundreds of scripts with few transactions repeating in each of them, then these repeated transactions are divided into tiny modules or blocks and are converted into user defined functions. These functions will be saved as header files and maintained in a common repository from where they will be called to the loadrunner scripts when they are required. These header files will be modified when there are changes in the requests and we can start the test executions without even opening the other scripts that are using these header files. The major advantages of this framework is preparing and maintaining the scripts will be easier and also it reduces the script debugging and reworking efforts.

Creating a user defined function:
Say for example Login, Home Page & Logout transactions will be common for all the applications. Instead of recording these requests repeatedly for each script, we suggest to record it once and convert it into user defined function and save it in a header file.

What are Header Files?
Header files are used to define all the functions, variables and constants in any function library that we want to use in our C Program. These files instruct the compiler on how to call a function using function names. Declaration of these header files start with #include and end with .h extension.

Below is the script generated in loadrunner for logging into an application (Login Transaction):

Now this App_Launch & App_Login requests have to be converted into a user defined function in a notepad and then save it as “.h” file (i.e.) header file. Similarly, all the repeated actions are converted into header files with user defined functions.
In the below example we have created a function by name “Login()” and we have saved the file as “Login.h”. Maintain these header files in a structured folder path for ease of use.

These header files will be called in the desired loadrunner scripts with their function name. For that we need to define the path of the header file in the “global.h” section of the Vugen script. Reason for placing the header files in the global.h section is that it makes the header file globally accessible across the script. 

Since the header files are in a location other than the script folder, we have to mention the entire path in the declaration. Also Make sure that the header files exist on the remote Load Generator machine at the same location when running the test from Controller.

After adding the header file, next add the function name in vuser_init()/Action()/vuser_end() section of the script. In our case the function name is Login(); and we have called it from vuser_init().

When we run the script, requests from the header file Login.h (i.e.) the App_Launch & App_Login transactions will be executed in Vugen.

This user defined functions can contain parameters & correlation functions and they will also be executed without any issues. If there are user defined parameters make sure that the same parameter is also created in the script.

Advantages of this framework:

1. Since we are recording all the repeated transactions only once, Scripting time will be drastically reduced.

2. In future if the requests in the header files are modified, then we need to debug only a single header file, instead of reworking on all the scripts. So script debugging time will be drastically reduced.

3. Header files can be stored in a shared path and same can be reused by the team.

Work Load Modelling using concurrent Vusers and Transactions Per Hour (TPH)

One of the important aspects of performance testing is Work Load Modelling (WLM) and in this article we will see how we can design it based on the below inputs from the client.

•        800 concurrent vusers
•        TPH is 25% of TPD (Transactions Per Day). Script wise TPD has been shared by the client.
•        Duration of the test will be 1 hour (3600 Seconds).

Now let’s see how we can design the WLM.

Below table shows the final WLM we have arrived at. In a step by step manner we will see how we calculated each parameter.

Step 1 – Calculate TPH

We know that TPH is 25 % of TPD. So our TPH will be.

TPH = 0.25 X TDP.

Step 2 – Calculate Load Distribution %

To find out the load distribution for each script, we need the Total TPH which will be the sum of all the scripts TPH. So our Load Distribution % will be.

Total TPH = ∑ TPH

Load Distribution % = (Script TPH / Total TPH) X 100

Load Distribution % value will be in decimal and we need to round it off.

Step 3 – Calculate Vusers

We know from the requirement, the Total Concurrent Vusers for the scenario will be 800. Now we need to distribute this across the scripts based on the scripts Load Distribution %. So our Vusers will be.

Vusers = (800 X Load Distribution %) / 100

Step 4 – Calculate Pacing

We know that the duration of the test will be 3600 seconds. So we will set the duration of the run in the controller and we will calculate only pacing so that the controller will decide upon the iterations required to achieve the TPH.  Since we know Vusers & TPH, our Pacing will be.

Pacing = (Vusers X Duration of the test in Seconds) / TPH

web_stream functions in loadrunner (web_stream_open & web_stream_close) and Error -26309: Another streaming with the same ID

Video streaming has become a common factor nowadays and most of the web pages are having videos streaming in them. So we will have to test the performance of the videos also, like the rendering time, buffer time, play time and so on.

Below are the loadrunner functions which get generated when we record a web page with video streaming in it. All the functions are straight forward and easy to understand.

If we notice, we have a ID assigned to the video in the web_stream_open function and the same ID is passed on to the other web_stream functions below. This ID is generated by loadrunner and will be unique to each video.

Script works fine in Vugen and when the same script is run with multiple concurrent users in controller, we get the below error message.

Error -26309: Another streaming with the same ID "3" has already been registered. Please set a new ID not registered

Error message means that one of the vuser is using the video with the ID = 3 and another vuser is trying to access the same video with ID = 3, and it is unable to stream the video. It is also requesting us to set a new unregistered ID to access the same video content.

Now, what we have to do is, we need to modify the ID in such a way that vusers do not clash when trying to stream the same video. Initially I tried using the inbuilt parameters like unique, random and vuser to replace ID, but still I got the same error. As a next step I wrote a C code using srand() & rand() to generate random numbers as ID for each vuser and pass it on to the argument ID. Below is the code snippet.

web_concurrent_start & web_concurrent_end

Need for Concurrent group functions:

A web page contains elements like html, jpeg, png, css service call and so on. When we try to load a web page of this kind, all these different elements make a parallel call to the servers to get loaded up. So at the end it is a single page that loads in front of our eyes.

These parallel concurrent calls can be simulated in Loadrunner using web_concurrent_start & web_concurrent_end functions. All the requests of the elements in a web page are recorded in-between these concurrent group functions. Thus making the simulation more realistic.

We can select this option under Recording Options -- Recording  -- HTML Based Script -- Non HTML - generated elements ( Record in separate steps and use concurrent groups )

What is concurrent execution?

Different multiple requests executed at the same point of time.

Characteristics:

• The web_concurrent_start & web_concurrent_end functions mark the beginning and end of a concurrent group.
• Functions (requests) included within the concurrent group are not executed immediately
• web_concurrent_start registers the functions (requests) for a concurrent execution.
• web_concurrent_end executes all the registered functions concurrently.
• These functions are supported for all Web scripts.

Garbage Collection (Minor & Major) & Garbage Collection types in detail

A fantastic article which explains in detail about how Garbage Collection works in different heap memory areas in Java & also about the various types of Garbage Collection Algorithms and best among them to chose for the application.

https://www.cubrid.org/blog/understanding-java-garbage-collection

Analyzing the trends in heap utilization and other heap memory related issues

Today I read few detailed articles on analyzing the heap memory and various heap utilization trends and various issues related to heap memory. Here I am sharing them. Hope this helps many....

https://plumbr.io/blog/memory-leaks/memory-leaks-fallacies-and-misconceptions
https://www.dynatrace.com/news/blog/how-to-identify-a-java-memory-leak/
https://www.dynatrace.com/resources/ebooks/javabook/analyzing-java-memory/

How to distribute the users in a single script across multiple load generators in controller - Loadrunner

When a script or group has more vusers then trying to simluate them in a single LG will cause high CPU utilization. To overcome this we need to distribute the vusers of the sript across multiple LG's.

Steps to do that.

1. Go to the Design tab in the Controller
2. Select the group or script whose vusers need to be distributed across multiple load generators.
3. Click the Virtual Users icon (second from the left, looks like two tiny persons in the icon, just above the list of groups) and The Vusers list for the group pops up.

4. Here I have 3 users which I need to spread across 3 LG's (10.100.11.235/10.100.11.236/localhost).

5. Select the Vusers and click the Details button then Vuser Information Dialog box pops up.
6. Select the LG from the Load Generator Name drop down and click OK. Repeat this step for all the Vusers in the list like shown below. Then close the dialog box.

7. Now we can see that the selected LG's are displayed against the Group Name.

How to do a Failover or Session Replication Testing?

Failover Testing – Nowadays we have applications which try to provide services to the customers 

24 X 7 unless and until they have planned maintenance window’s. Example for this is any banking application. Moreover, clustered servers are deployed these days to ensure the performance, availability and scalability of the applications are improved.

So in Failover testing we will be testing the availability of the application when one of the servers goes down in the cluster. Or in other words we can check how the other online servers are handling the load when few of the servers in the cluster goes offline.  

This failover testing is also known as session replication testing. Session replication is a mechanism used to replicate the data stored in a session across different instances. However, the replicated instance must be part of the same cluster. When session replication is enabled in a cluster environment, the entire session data is copied on a replicated instance. So when one instance goes offline the user will be able to use the same session without any interruption because of its replication. This is to ensure that business is carried out smoothly.

Failover or session replication testing can be done on both Application & Database servers. Usually failover testing is done with the peak load.

Approach:

Failover Table

In the above table we can see that there are 2 server instances. We have to divide the duration of the test into time slots to perform this.

Phase 1 is the Ramp up period, where all the users are brought into the system and they take some time to reach the steady state. In this phase the load will be balanced between 2 server instances.

Phase 2 is where the first failover begins. In our case we make the Server 1 to go offline. Now the CPU utilization of Server 2 will increase since it takes the additional load from Server 1.

Phase 3 we will bring back the Server 1 to online. So again the load should be shared among the server instances. Meaning Server 1 CPU utilization will start to grow and Server 1 CPU utilization will start to reduce and they will reach a balancing point. We need to measure the recovery time of Server 1

Phase 4 is where the second failover begins. In our case we make the Server 2 to go offline. Now the CPU utilization of Server 1 will increase since it takes the additional load from Server 2.

Phase 5 is same as that of Phase 3.

Failover CPU Utilization - Sample

Test Report:

Below are the metrics to be captured in a Failover test report.

• Server recovery time in Phase 3 & 5.
• CPU & Memory utilization of both the servers in each Phase.
• Response time of all the transactions in each phase.

Understanding the relationship between hits per second & throughput in performance testing

First let's see what Hits per second & Throughput means.

Hits per second - Number of request hits the web server per second.

Throughput - Amount of data in bytes (Response) that the Vusers received from the server in a second. Measured in bytes/second.

In Analyzer we have an option to merge the graphs, using that we can merge the Hits per Second & Throughput graph to understand how the application is performing.

Below are the possible scenarios.

1. When Throughput graph is plotted higher than the Hits per second graph then  the application is performing great, which means the servers are processing the requests at a rate greater than the requests are reaching the server.

2. When both the graphs are parallel or overlapping with each other then the application is performing good, which means the servers are processing the requests at a same rate the requests are reaching the server. (See the below Image).

3. When Throughput graph is plotted lower than the Hits per second graph then the application is having issues, which means the servers are processing the requests at a rate lower than the requests are reaching the server.

Understanding the relationship between the Throughput & Response Time in performance testing

First let's see what Throughput & Response Time mean.

Throughput - Amount of data in bytes (Response) that the Vusers received from the server in a second. Measured in bytes/second.

Response Time - It is the total time it takes from when a user makes a request until they receive a response. Measured in seconds.

So it is evident that both are related with the response of the application.

Lets see how we can extrapolate the performance of the application from the Analysis Summary
(Under Statistics Summary) using Throughput & Response Time.

Basically you need to compare the Total Throughput (Bytes) & Response Time between the runs to identify how well the application is performing.

Comparison between the runs:

• If throughput is increasing and response time is consistent or decreasing then there are no issues, the application is performing good.
• If throughput is increasing and response time is increasing then there is issue, the application is not able to process the growing huge bytes of data. So the requests would have been queued as a result response time increased due to the wait time.
• If throughput is decreasing and response time is increasing then there is a serious issue, the application is not even able to process a minimum load. Which should be looked upon immediately.

So the conclusion is, If we are able to download large bytes of data in less response time then your application is performing good.

More about Blocks in Run Time Settings (RTS)

If at all we would like to iterate a set of Actions in the Run Logic we can use Blocks.

Below is the flow for an e-commerce application.

Login --> Search Books --> Search Electronics --> Place Order --> Logout

• Our criteria is that each user should repeat the Search Actions 10 times. 
• So we have grouped Search Books & Search Electronics Action under Block. (Just rt.click on Run and Select Add Block then rt.click on the Block and Select the Actions)
• On the top right corner we can see group properties in which I have mentioned the number of Iterations for the Block as 10. So each user will execute the Block 10 times.
• In the Run Logic I have chosen Sequential, So Actions will be executed one after the other Sequentially. 
• Instead we can also chose Random. So that Actions will be executed Randomly.
• In the above image we can see that, number of User iterations is 5 for the whole Run Logic, which means each user will execute the Block 10 times and on the whole Blocks will be executed to a total of 50 times.

Note:

• When we are bringing all the Actions under block and if we are going to use the Block iterations instead of the Run Logic iterations, then please note that Pacing is not applicable to the Blocks. 
• So you have to give the pacing value as think time at the end of the last Action in the Block.
• Say for example we are moving Login and Logout to vuser init & vuser end respectively and rest all actions as a block in the Run section then pacing should be added as think time function at the end of Place Order Action. 

More about Date & Time parameter in Loadrunner

We all know that parameterization is used to pass unique user inputs to the application and we have different type of parameters to achieve this uniqueness. One such parameter is Date & Time parameter. Here Date & Time values are appended to the text to generate unique user parameters.

Image A

We are all familiar with this. But most of us are not familiar with the Offset option at the bottom of the parameterization dialog box in Image A , which is what will be explained in this post.

Offset - This defines the number of days the date value should be adjusted in the past or in the future.
Simply, Offset takes you to the past & future dates & time.

Offset Parameter by  -  this is where you define the number of days & time value for which the adjustment should happen. but we have not defined if this should be in the past or in the future.This can be done in the next option.

In the Image A we are offsetting the date & time parameter by 1 day.

Prior to current date - When you check this box, dates are adjust to the past. If this box is unchecked dates are adjust to the future.

In the Image A, Prior to current date option is checked which means we are offsetting the date & time parameter by 1 day in the past. So the Parameter value will be 2018-06-26.

Working days only -  When you check this box only weekdays are considered (i.e) Saturday & Sunday will not be included in the parameter calculation.  If this box is unchecked all the 7 days of the week will be included in the parameter calculation.

Where Offset option will be useful?

1. If you are doing a search in the application to retrieve records from the past days.
2. If your application is using the future dates to mark the due dates.

Simply we can use this, wherever the application uses past & future dates.

Note : All these can also be done using the lr_save_datetime loadrunner function.

How to convert a Fiddler Session into Vugen script

What is Fiddler?

Fiddler is web debugging tool which capture all the traffic between the browser (client) & the server.

Why should we covert a fiddler session into a Vugen script?

When we are trying to record a application which retrieves responses of huge bytes Vugen might crash. So as a workaround we can convert a fiddler session into a Vugen script.

How to do that?

It very simple.

1. Fiddler is an open source tool. First download & install it in your system.
2. Next start the fiddler and launch the browser. Make sure that all other browsers and browser sessions are closed. If not, then the traffic across the all the browsers would be captured in fiddler.
3. In Fiddler, in the right pane we can find the Filters tab under which check the show only traffic from and select the browser session that you have launched.

4. Now perform the flow which you wanted to record in Vugen, the same will be captured as Fiddler session.
5. Then save the session as a .SAZ ( Session Archive Zip) file. File --> Save --> All Sessions 

6. Now import the .SAZ file in Vugen, You could see that Fiddler Session into Vugen script.

Drawback:
The only drawback is that we have to add the transactions only after the vugen script is generated.

Debug a Vugen script using developer tools.

Whenever the application under test is upgraded with latest code which may have UI changes (like few elements in the page might be removed or added or modified) or in other words
the requests would have been modified or added or removed, there are high chances that our vugen script might not work.

To debug scripts of these kind we can use developer tools instead of re-recording the whole script as this approach saves a lot of time.

• After launching the browser press F12 to open the developer tools.

• All the requests sent from the client (browser) to server will be captured under the Network Tab in developer tools.

• Launch the application and capture the request which fails in the script in the developer tool.

• When you click on the request you can see Headers Tab which holds all the information about the request like Request URL, Request Method, Request Headers & Form Data.

• From data is the section where the request parameters are passed on. Compare this Form data with the Item Data in the script request and look out for changes. If there are differences then update the script with the new form data and run the script, this will more likely resolve the issue.

• The Image A below shows the login request in the vugen script and the same same request captured in developer tool in Image B (Highlighted in RED box).

Image A

Image B

• You can clearly see that the parameters under Item data in the script are captured under Form Data in the developer tool.

• On clicking on the view source (Highlighted in BLUE circle in Image B) we can view the parameters in a way it will be formatted in the request (as shown in Image C), which will be more easy to compare and analyze.

Image C

• Also we can you the Inspect element option (Highlighted in GREEN circle on the Left top corner in Image B) to debug the scripts. Turn on this option and select any element in the web-page to get the Element ID & Element Value. This way also we can compare & update the Element ID & Element Value (Item Data) in the script.

How to start the controller from the command line automatically?

Below is the command line argument to invoke the controller

Wlrun.exe –TestPath C:\Temp\Scenario1.lrs –ResultLocation C:\Temp –ResultCleanName Res1 –Run

wlrun.exe is the controller executable file
-TestPath mentions the location from where the Test Scenario is to be invoked
-ResultLocation mentions the location where the Raw Result has to be saved
-ResultCleanName mentions the name with which Raw Result has to be saved

-ResultLocation & -ResultCleanName arguments can be merged together into a single argument
-ResultName

So the command now becomes

Wlrun.exe –TestPath C:\Temp\Scenario1.lrs -ResultName C:\Temp\Res1 –Run

-ResultName mentions the location & filename with which Raw Result has to be saved

If we would like to invoke the Analysis once the test completes then add the argument
–InvokeAnalysis to the above command

So the command now becomes

Wlrun.exe –TestPath C:\Temp\Scenario1.lrs -ResultName C:\Temp\Res1 –Run –InvokeAnalysis

Note

• If the scenario does not specify where the results have to be saved and also even if one of the above parameters was not passed, the scenario will not run.
• The results will always be automatically collated upon scenario termination.
• The results will always be automatically overwritten.

Now comes the automation part.

1. Copy the above command in a notepad and save the file as batch file. Example: ControllerAutomate.bat
2. Now open the Windows Task Scheduler and click Create Basic Task.
3. Mention a Name of the Task in Create A Basic Task. Example -  Controller Scheduler
4. In the Trigger mention when you want to trigger the batch file. Select One Time and set the Date & Time.
5. In the Action Select Start a Program, then browse and Select the batch file.
6. Finish shows the summary of all the selections we have made in the above steps. Verify & click Finish.

Thats it, Windows Task Scheduler will trigger the batch file in the mentioned Date & Time.

Note

• Make sure that Controller is closed before trying to automatically trigger it.

Difference between Concurrent & Simultaneous users in Performance Testing.

Understanding the difference between the Concurrent and Simultaneous users is very much important in generating the type of user load for performance testing.

Concurrent users:

Concurrent users are connected to your test application and are all requesting work at some time intervals but not all at once and not for the same thing (same request or page).

In loadrunner concurrency between the user transactions can be achieved by introducing randomized think time (lr_think_time) and the end of transactions.

Example:

• Below is the table of 5 users working in an e-commerce application.
• We could see that each user is in a different transaction denoted by x mark.
• Transactions highlighted in Green are completed by the user and in yellow are yet to be started which also differs from user to user.

Simultaneous users:

Simultaneous users are connected to your test application and who are all requesting work at the same time and for the same thing (same request or page).

In loadrunner simultaneous user can be achieved by using lr_rendezvous function above the transaction for which we need a simultaneous hit to the server or by selecting all user simultaneously in the controller during the load test.

Example:

• Below is the table of 5 users working in an e-commerce application.
• We could see that all the users are in the same search cart transaction denoted by x mark.
• Transactions highlighted in Green are completed by the user and in yellow are yet to be started which also remains the same for all users.

Pacing Calculation in Loadrunner - Performance Testing

What is Pacing?

• Pacing is the time interval between the iterations. 
• It ensures better gap between the user sessions in the load test.
• It is needed to achieve the required TPS in the load test. 
• Ignoring the pacing will flood the server with requests continuously thus making the test inappropriate.

Pacing can be set in the Run Time Settings.

1. As soon as the previous iteration ends

New iteration will start as soon as the previous iteration ends. Which means Pacing = 0.

2. After the previous iteration ends - with

New iteration will start at fixed or random delay after the previous iteration ends.

Fixed - Mention the exact delay in seconds.

Random - Mention the min and max delay in seconds and pacing will be selected between the specified range.

Example: Pacing = 60 Seconds and Time taken for 1 iteration = 50 seconds.

So the First iteration will end at 50 secs and Second iteration will start after 60 secs from the end of first iteration. Since Pacing = 60 secs.

Here pacing acts as a wait timer.

3. At Fixed or Random intervals - every

Here the Pacing timer for the new iteration will begin when the previous iteration starts and the iterations will be fired at the exact timer. In this case Pacing time should be higher than the Time taken for 1 iteration or else the second iteration will start right after the end of the first iteration.

Fixed - Mention the exact delay in seconds.

Random - Mention the min and max delay in seconds and pacing will be selected between the specified range.

Example 1 : Pacing = 60 Seconds and Time taken for 1 iteration = 50 seconds.

Pacing timer will start with the iteration. First iteration will end at 50 secs and after which there will be 10 secs gap after which the second iteration will start.

Example 2 : Pacing = 60 Seconds and Time taken for 1 iteration = 70 seconds.

Pacing timer will start with the iteration. First iteration will end at 70 secs and after which there will be no gap since the Time taken for 1 iteration has surpassed the pacing time. So the second iteration will start immediately.

Here pacing just acts as a timer.

Formulas to calculate Pacing

Formula 1:

P = ( D - ( I * Ti ) ) / ( I - 1)

where

P   = Pacing time in secs
D  = Duration of the test in secs
I   = No. of Iterations
Ti = Time taken for 1 Iteration in secs

Formula 2:

simplified form of formula 1

P = D / I

where

P   = Pacing time in secs
D  = Duration of the test in secs
I   = No. of Iterations

Formula 3:

P = ( V * D) / Ts

where

P   = Pacing time in secs
V = No. of users in the script for which pacing is calculated
D  = Duration of the test in secs
Ts = Total no of Transactions to be achieved in the test for the script, for which pacing is calculated