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.