When a script is recorded, it covers single and straight flow of the subject application. Whereas, a real user may perform multiple iterations of any process before he logs out. The delay between clicking buttons (think time) will vary from person to person. Chances are that some real users access your application over DSL and some access it over a dial-up. So, in order to get the real feel of end user, we need to enhance our scripts to be exact match, or at least very close in behaviour to real users. The above is the most significant consideration when conducting “Performance Testing”, but there is more to a VU Script. How will you gauge the precise amount of time taken by a VUser when SUL is undergoing a performance test? How would you know if the VUser has passed through or failed at certain point? What is the cause behind the failure, whether some backend process failed or the server resources were limited? We need to enhance our script to help answer all above questions.
Using Transactions Understanding Think Time, Rendezvous Points and Comments Inserting Functions through menu What is Parameterization? Run Time Settings and their impact on VU simulation
Run Logic Pacing Log Think Times Speed Simulation Browser Emulation Proxy
Using Transactions
Transactions are mechanics to measure server response time for any operation. In simple words, the use of “Transaction” helps measure the time taken by the system for a particular request. It can be as small as a click of a button or an AJAX call upon losing focus from the text box.
Applying transactions is straightforward. Just write one line of code before request is made to the server and close the transaction when the request ends. LoadRunner requires only a string as transaction name.
To open a transaction, use this line of code:
To close the transaction, use this line of code:
The
LR_AUTO
LR_PASS
LR_FAIL
Example: lr_end_transaction(“My_Login”, LR_AUTO); lr_end_transaction(“001_Opening_Dashboard Name”, LR_PASS); lr_end_transaction(“Business_Workflow_Transaction Name”, LR_FAIL); Points to note:
Don’t forget, you are working with “C” and that is a case-sensitive language.
Period (.) character is not allowed in transaction name, although you can use spaces and underscore.
If you’ve branched your code well and added checkpoints to verify the response from the server, you can use custom error handling, such as, LR_PASS or LR_FAIL. Otherwise, you can use LR_AUTO and LoadRunner will automatically handle server error (HTTP 500, 400 etc.)
When applying transactions, ensure there is no think_time statement being sandwiched or otherwise your transaction will always include that period.
Since LoadRunner requires a constant string as transaction name, a common problem when applying transaction is mismatch of string. If you give a different name when opening and closing a transaction, you will at least 2 errors. Since the transaction you opened was never closed, LoadRunner will yield an error. Besides, the transaction you are trying to close was never opened, hence resulting an error.
Can you use your intelligence and answer to yourself which of the above error will be reported first? To validate your answer, why not make your own mistake? If you had answered right, you are on track. If you answered wrong, you need to focus.
Since LoadRunner automatically takes care of synchronization of requests and response, you will not have to worry about response when applying transactions.
Understanding Think Time, Rendezvous Points and Comments
Rendezvous Points
Rendezvous Points means “meeting points”. It is just one line of statement that tells LoadRunner to introduce concurrency. You insert rendezvous points into VUser scripts to emulate heavy user load on the server. Rendezvous points instruct VUser to wait during test execution for multiple VUser to arrive at a certain point, so that they may concurrently perform a task. For example, to emulate peak load on the bank server, you can insert a rendezvous point instructing 100 VUser to deposit cash into their accounts at the same time. This can be achieved easily using rendezvous. If the rendezvous points are not places correctly, the VUser will be accessing different parts of the application – even for the same script. This is because every VUser gets different response time and hence few users lag behind. Syntax: lr_rendesvous(“Logical Name”); Best Practices:
Prefix a rendezvous point with “rdv_” for better code readability; e.g. “rdv_Login”
Remove any immediate think time statements
Applying rendezvous points in a script view (after recording)
Comments
Add comments to describe an activity, a piece of code or a line of code. Comments help make the code understandable for anyone referring to it in the future. They provide information about specific operation and separate two sections for distinction. You can add comments
While recording (using tool)
After recording (directly writing in code)
Best Practice: Mark any comments on the top of each script file
Inserting Functions through menu
While you can directly write simple lines of code, you may need a clue to recall a function. You can also use Steps Toolbox (known as Insert Function prior to version 12) to find and insert any function directly into your script. You can find Steps Toolbar under View àSteps Toolbox.
This will open a side window, look at the snapshot:
What is Parameterization?
A parameter in VUGen is a container that contains a recorded value that is replaced for various users. During the execution of the script (in VUGen or Controller), the value from an external source (like .txt, XML or database) substitutes the previous value of the parameter. Parameterization is useful in sending dynamic (or unique) values to the server, for example; a business process is desired to run 10 iterations but picking unique user name every time. It also helps in stimulating real-like behavior to the subject system. Have a look at below example: Problem examples: Business process works only for the current date which comes from the server, hence can’t be passed as a hardcoded request. Sometimes, the client application passes a Unique ID to the server (for example session_id) for the process to continue (even for a single user) – In such a case, parameterization helps. Often, the client application maintains a cache of data being sent to and from the server. As a result, server is not receiving a real user behavior (in case server runs different algorithm depending upon search criteria). While VUser script will execute successfully, the performance statistics drawn will not be meaningful. Using different data through parameterization helps emulates server side activity (procedures etc.) and exercises the system. A date that is hard-coded in the VUser during recording may no longer be valid when that date has passed. Parameterizing the date allows VUser execution to succeed by replacing the hard-coded date. Such fields or requests are the right candidates for parameterization.
Click here if the video is not accessible
Run Time Settings and their impact on VU simulation
Run Time Settings bear as much significant as your VUGen Script. With varying configurations, you can obtain different test designs. This is why, you may end up in non-repeatable results if Run Time Settings are not consistent. Let’s discuss each attribute one by one.
Run Logic
Run Logic defines the number of times all actions will be executed, except vuser_init and vuser_end. Probably this makes clearer why LoadRunner suggests keeping all the Login code within vuser_init, and Logout part in vuser_end, both exclusively. If you’ve created multiple actions, let’s say, Sign in, Open Screen, Calculate Rental, Submit Funds, Check Balance and logout, then, below scenario will take place for each VUser: All VUsers will login, execute Open Screen, Calculate Rental, Submit Funds, Check Balance – then – again Open screen, Calculate rentals…and so on – iterating 10 times – followed by logout (once).
This is a powerful setting enabling to act more like a real user. Remember, a real user does not login and logouts every time – he, usually, repeats same steps.
How many times do you click “inbox” when checking you email before logout?
Pacing
This is important. Mostly people are unable to understand the different between pacing and think time. The only difference is, “pacing refers to the delay between iterations” whereas think time is the delay between any 2 steps. Recommended setting depends upon the test design. However, if you are looking to have aggressive load, consider opting “As soon as the previous iteration ends”
Log
A log (as generally understood) is a bookkeeping of all events while you run LoadRunner. You can enable log to know what’s happening between your application and your server. LoadRunner gives powerful logging mechanism which is robust and scalable on its own. It allows you to keep only “Standard Log” or a detailed, configurable extended log or disable it altogether. A standard log is informative and easily understandable. It contains just the right amount of knowledge you will generally require troubleshooting your VUser scripts. In the case of Extended Log, all the Standard log information is a subset. Additionally, you can have parameter substitution. This tells LoadRunner component to include complete information of all the parameters (from parameterization) including requests, as well as response data. If you include “Data Returned by Server” then your log will go in length. This will include all the HTML, tags, resources, non-resources information included right within the log. The option is good only if you need serious troubleshooting. Usually, this makes the log file very big in size and not easily comprehendible. As you could have guess by now if you opt for “Advance Trace”, your log file will be massive. You must give it a try. You will notice the amount of time taken by VUGen has also increased significantly, although this will have no impact on the transaction response time reported by VUGen. However, this is very advance information and maybe useful if you understand the subject application, the client to server communication between your application and hardware as well as protocol level details. Usually, this information is dead by essence since it requires extreme efforts to understand and troubleshoot.
Tips:
No matter how much time VUGen takes when log is enabled, it has no impact on the transaction response time. HP calls this phenomenon as “state of the art technology.”
Disable log if it is not required.
Disable log when you are finished with your scripts. Including scripts with logging enabled will cause controller to run slower and report nagging messages.
Disabling log will increase the capacity of the maximum number of users you can simulate from LoadRunner.
Consider using “Send message only when error occurs” – this will mute unnecessary information messages and report only error related messages.
Think Times
Think Time is simply the delay between two steps. Think Time helps replicates user behavior since no real user can use any application like a machine (VUGen). VUGen generates think time automatically. You still have complete control to remove, multiply or fluctuate the duration of think time. To understand more, for example, a user may open a screen (that is a response followed by a request) and then provide it is username and password before hitting enter. The next interaction of the application to the server will happen when he clicks “Sign In”. The time a user took to type his username and password is Think Time in LoadRunner.
If you are looking to simulate aggressive load on the application, consider disabling think time completely.
However, to simulate a real like behavior, you can “User Random Think Time” and set the percentages as desired. Consider using Limit Think Time to a legitimate period. Usually, 30 seconds is fairly good enough.
Speed Simulation
Speed simulation simply refers to bandwidth capacity for each client machine. Since we are simulating thousands of VUser’s through LoadRunner, it is amazing how simple LoadRunner has made to control the bandwidth/network speed simulation. If you are customers access your application over 128 Kbps, you can control it from here. You will get to simulate “real like behavior” which should help getting the right performance statistics.
The best recommendation is to set to Use maximum bandwidth. This will help disregard any network related performance bottlenecks and focus on any potential issues in the application first. You can always run the test multiple times to see varying behavior under different circumstances.
Browser Emulation
User experience does not depend upon the browser an end user is using. Clearly, this is beyond the scope of Performance measures. However, you can choose which browser you wish to emulate.
Can you answer to yourself when exactly it will really matter for you to select the right browser in this configuration?
You will use this configuration if you are subject application is a web application, returning different responses for different browsers. For example, you get to see different images and contents for IE and Firefox etc. Another important setting is Simulate browser cache. If you want to gauge the response time when cache enabled, check this box. If you are looking for worst case situation, this is obviously not a consideration. Download non-HTML resources will let LoadRunner download any CSS, JS and other rich media. This should be remained checked. However, if you which to eliminate this from your performance test design, you can uncheck this.
Proxy
It is best to eliminate proxy completely from your Test Environment – this will make the test results unreliable. However, you might face situations where it is inevitable. In such a situation, LoadRunner does facilitate you with proxy settings. You will be working (or should be working) with No proxy setting. You can obtain it from your default browser. However, don’t forget to check which browser is set to default and what proxy configuration for default browser is.
If you are using a proxy and it requires authentication (or a script) then you can click on the Authenticate button which leads to a new window. Refer to below screenshot.
Use this screen to provide username and password to get authenticated on the proxy server. Click OK to close the screen.
Congratulations. You are done with configuration your VUGen script. Don’t forget to configure it for all your VUser scripts.
