RUN TIME SETTINGS

 Run Logic:

Every Vuser script contains three sections: vuser_init, Run (Actions), and vuser_end.

You can instruct a Vuser to repeat the Run section when you run the script. Each repetition is known as iteration. The vuser_init and vuser_end sections of a Vuser script are not repeated when you run

multiple iterations.

Number of Iterations: The number of iterations. LoadRunner repeats all of the Actions

the specified number of times. If you specify scenario duration in the Controller’s scheduling settings, the duration setting overrides the Vuser iteration settings. This means that if the duration is set to

five minutes (the default setting), the Vusers will continue to run as many iterations as required in five minutes, even if the run-time settings specify only one iteration. When you run scripts with multiple actions, you can indicate how to execute the actions, and how the Vuser executes them:

Action Blocks: Action blocks are groups of actions within your script. You can set the properties of each block independently—its sequence, iterations, and weighting.

Sequence: You can set the order of actions within your script. You can also indicate whether to perform actions sequentially or randomly.

Iterations: In addition to setting the number of iterations for the entire Run section, you can set iterations for individual actions or action blocks. This is useful, for example, in emulating a commercial site where you perform many queries to locate a product, but only one purchase.

Best Practice: The number of iterations will depend on the customer’s specifications of the each individual test series. Normally, the next iteration starts as soon as the previous iteration ends, again depending on the test customer’s specifications.

Pacing:

The Pacing Run-Time settings let you control the time between iterations. The pace tells the Vuser how long to wait between iterations of your actions. You instruct the Vusers to start each iteration using one of the following methods:

·          As soon as the previous iteration ends: The new iteration begins as soon as possible after the previous iteration ends.

·          After the previous iteration ends with a fixed or random delay of …: Starts each new iteration a specified amount of time after the end of the previous iteration. Specify either an exact number of seconds or a range of time. For example, you can specify to begin a new iteration at any time between 60 and 90 seconds after the previous iteration ends. The actual amount of time that the Vuser waits between the end of one iteration and the start of the next one appears in the Execution Log whenyou run the script.

·          At fixed or random intervals, every … [to ...] seconds: You specify the time between iteration—either a fixed number of seconds or a range of seconds from the beginning of the previous iteration. For example, you can specify to begin a new iteration every 30 seconds, or at a random rate ranging from 30 to 45 seconds from the beginning of the previous iteration. Each scheduled iteration will only begin when the previous iteration is complete.

Best Practice: We normally use this option “As soon as the previous iteration ends”, which can change

according to client requirements.

The detailed description about different option on the logging window is given as follows:

Enable Logging

This option enables automatic logging during replay—VuGen writes log messages that you can view in the Execution log.

Log Options

The Log run-time settings allow you to adjust the logging level depending on your development stage. You can indicate when to send log messages to the log: Send messages only when an error occurs or always send messages. During development, you can enable all logging. Once you debug your script and verify that it is functional, you can enable logging for errors only.

Setting the Log Detail Level

You can specify the type of information that is logged, or you can disable logging altogether, which is done when we are running scripts in the controller as it results unnecessary usage of system resources and can skew the performance results.

Standard Log: Creates a standard log of functions and messages sent during script execution to use for debugging. Disable this option for large load testing scenarios.

Extended Log: Creates an extended log, including warnings and other messages. Disable this option for large load testing scenarios. If logging is disabled or if the level is set to Extended, adding it to a scenario does not affect the log settings. You can specify which additional information should be added to the extended log using the extended log options:

·          Parameter substitution: Select this option to log all parameters assigned to the script along with their values.

·          Data returned by server: Select this option to log all of the data returned by the server.

Advanced trace: Select this option to log all of the functions and messages sent by the Vuser during the session. This option is useful when you debug a Vuser script.

Best Practice:

As it has been mentioned in the description above that generally, we check all the three logging options if and when we are correlating & parameterizing the scripts. This gives us all the details of  communication with the server. But, while running the scripts in the scenario, disable the “Enable logging” checkbox unless it becomes necessary to see the details again, because otherwise it will waste hard disk space and memory of the load generators, which can skew our load testing results. We check “Send Messages only when an Error” option as this helps to troubleshoot if there is some problem while running the scenario.

Think Time:

The description about different options on Think Time window is as follows:

Ignore think time: Ignore the recorded think time—replay the script ignoring all lr_think_time functions.

Replay the think time: The second set of think times options let you use the recorded think time.

·          As recorded: During replay, use the argument that appears in the lr_think_time function. For example, lr_think_time(10) waits ten seconds.

·          Multiply recorded think time by: During replay, use a multiple of the recorded think time. This can increase or decrease the think time applied during playback. For example, if a think time of four seconds was recorded, you can instruct your Vuser to multiply that value by two, for a total of eight seconds. To reduce the think time to two seconds, multiply the recorded time by 0.5.

·          Use random percentage of the recorded think time: Use a random percentage of the recorded think time. You set a range for the think time value by specifying a range for the think time. For example, if the think time argument is 4, and you specify a minimum of 50% and a maximum of 150%, the lowest think time can be two (50%) and the highest value six (150%). This can be said to be the best way of putting think time in the scripts because even in the real world, not two people will fill any particular form in same time.

·          Limit think time to: Limit the think time’s maximum value.

Best Practice:

In all of our scenarios, we choose to ignore the Think Time. The reason behind this is that we do not have a reliable and accurate way to measure think time in our production environment and there fore would be skewing our test results by guessing at the Think Time. On some occasions, based on customer’s test specifications, we may use Think Time to slow our transactions in the scenario. This is usually done during a duration type test when the normal pace of our transactions is very fast and we need to extend that duration for the purpose of achieving the test goals. Author believes that it would be best to go by “Use random percentage of the recorded think time” option. It would help us in emulating the real life scenario because no two people in this world will do any activity in same time. Sometimes it is good to go into the script and modify recorded think times (say to make them all x seconds) and add think times to proper places where they are missed to ensure a fixed, controlled wait between every user action.

Miscellaneous:

Continue on Error: This setting instructs Vusers to continue script execution when an error occurs. This option is disabled by default.

Fail open transactions on lr_error_message: This option instructs VuGen to mark all transactions in which an lr_error_message function was issued, as Failed.

Generate Snapshot on Error: This option generates a snapshot when an error occurs. You can see the snapshot by viewing the Vuser Log and double clicking on the line at which the error occurred.

Multithreading:

The primary advantage of a multithread environment is the ability to run more Vusers per load generator. Only thread safe protocols should be run as threads. The Controller uses a driver program (e.g., mdrv.exe, and r3vuser.exe) to run your Vusers. If you run each Vuser as a process, then the same driver program is launched (and loaded) into the memory again and again for every instance of the Vuser. Loading the same driver program into memory uses up large amounts of RAM (random access memory) and other system resources. This limits the numbers of Vusers that can be run on any load

generator. Alternatively, if you run each Vuser as a thread, the Controller launches only one instance of the driver program (e.g., mdrv.exe), for every 50 Vusers (by default). This driver process/program launches several Vusers, each Vuser running as a thread. These threaded Vusers share segments of the memory of the parent driver process. This eliminates the need for multiple re-loading of the driver

program/process saves much memory space, thereby enabling more Vusers to be run on a single load generator.

Automatic Transactions:

You can instruct LoadRunner to handle every step or action in a Vuser script as a transaction. This is called using automatic transactions. LoadRunner assigns the step or action name as the name of the transaction. By default, automatic transactions per action are enabled.

·         • To disable automatic transactions per action, clear the Define each action as a transaction check box. (enabled by default)

·         • To enable automatic transactions per step, check the Define each step as a transaction check box. (disabled by default)

Best Practice:

1) In the Miscellaneous settings, the Error Handling is left unchecked.

2) Due to limited hardware and time, mostly we use Vusers as threads.

3) In most cases, we are measuring both the action and each step. This additional data helps us to analyze the transactions and identify the slowest pieces of the application, as this is where we would start to focus on enhancing the performance of the application. Normally we also insert transactions manually into the script, which will give us the timings of any particular transaction. To set proper order of the timings of the transactions, we normally prefix the transaction name by numbers like 01, 02, 03 etc.

This naming has helped us to analyze the timings of different components of the application more efficiently. Please DO NOT include think time and, output messages or any other custom program logic in the start and end transaction.

4) “Generate Snapshot on Error” option will be checked in future. This will be very useful when there are errors and you want to see or share how the error pages look.

Speed Simulation:

Using the Speed Simulation settings, you can select a bandwidth that best emulates the environment under test. The following options are available:

Use maximum bandwidth: By default, bandwidth emulation is disabled and the Vusers run at the maximum bandwidth that is available over the network.

Use bandwidth: Indicate a specific bandwidth level for your Vuser to emulate. You can select a speed ranging from 14.4 to 512 Kbps, emulating analog modems, ISDN, or DSL.

Use custom bandwidth: Indicate a bandwidth limit for your Vuser to emulate. Specify the bandwidth in bits, where 1 Kilobit=1024 bits.

Best Practice:

Since most of our customers use the high speed Internet, we normally use the option of “Use Maximum bandwidth”. It might be another challenge to load test the application at low internet speeds.

Setting Browser Emulation Properties:

Simulate browser cache: This option instructs the Vuser to simulate a browser with a cache. A cache is used to keep local copies of frequently accessed documents and thereby reduces the time connected to the network. By default, cache simulation is enabled. When the cache is disabled, LoadRunner still

downloads each page image only once. When running multiple Vusers from the Controller, every Vuser uses its own cache and retrieves images from the cache. If you disable this option, all Vusers emulate a browser with no cache available.

You can also set the following two browser cache options:

·          Cache URLs requiring content (HTML): This option instructs VuGen to cache only the URLs that require the HTML content. The content may be necessary for parsing, verification, or correlation. When you select this option, HTML content is automatically cached. This option is enabled by default.

·          Check for newer versions of stored pages every visit to the page: This setting instructs the browser to check for later versions of the specified URL, than those stored in the cache. When you enable this option, VuGen adds the “If-modified since” attribute to the HTTP header. This option guarantees that the most recent version of the page always appears, but generates more traffic during scenario

execution. By default, browsers do not check for newer resources, and therefore this option is disabled.

·          Download non-HTML resources: This option instructs Vusers to load graphic images when accessing a Web page during replay. This includes both graphic images that were recorded with the page, and those, which were not explicitly recorded along with the page. When real users access a Web page, they wait for the images to load. Therefore, enable this option if you are trying to test the entire system, including end-user time (enabled by default). To increase performance and not emulate real users, disable this option.

·          Simulate a new user each iteration: Instructs VuGen to reset all HTTP contexts between iterations to their states at the end of the init section. This setting allows the Vuser to more accurately emulate a new user beginning a browsing session. It deletes all cookies, closes all TCP connections (including keep-alive), clears the emulated browser’s cache, resets the HTML frame hierarchy (frame numbering

will begin from 1) and clears the user-names and passwords. This option is enabled by default.

·          Clear cache on each iteration: Clears the browser cache for each iteration in order to simulate a user visiting a Web page for the first time. Clear the check box to disable this option and allow Vusers to use the information stored in the browser’s cache, simulating a user who recently visited the page.

Best Practice:

We check the option “Simulate Browser Cache”, which helps to emulate the cache for browser. We check “Simulate a new user each iteration” as we normally record user login, logout, and transaction all in the Action section of the script AND we want to simulate new users between iterations. This will reset the context (such as cookies) during the script playback between iterations.

We also check following options:

·         “Download non-HTML resources”

·          “Clear cache on each iteration”.

As it has been already explained about the above 2 points that these help to emulate a real life user, therefore we use check these options to emulate real life load on the applications.

Setting Proxy Options:

By default, the Vuser uses the proxy settings of the browser used for recording in the Web recording options. It is recommended that you use the same settings for record and replay.

The following proxy options are available in the Run-Time settings.

·          No proxy: All Vusers always use direct connections to the Internet. This means that the connection is made without using a proxy server.

·          Obtain the proxy settings from the default browser: All Vusers use the proxy settings of the default browser from the machine upon which they are running.

·          Use custom proxy: All Vusers use a custom proxy server. You can supply the actual proxy server details or the path of a proxy automatic configuration script (.pac file) that enables automatic configuration. To supply the details of the server, you specify its IP address or name and port. You can specify one proxy server for all HTTP sites, and another proxy server for all HTTPS (secure) sites.

Best Practice:

Author has also observed that some of the companies use proxy servers to get connected

to the server due to security reasons, therefore it is best to use “Obtain the proxy settings

from the default browser” option.

Preferences:

Image and Text Checks:

The Enable image and text checks option allows the Vuser to perform verification checks during replay by executing the verification functions: web_find or web_image_check.This option only applies to statements recorded in HTML-based mode. Vusers running with verification checks use more memory than Vusers who do not perform checks (disabled by default).

Generating Web Performance Graphs:

Instructs a Vuser to collect data used to create Web Performance graphs. You view the Hits per Second, Pages per Second, and Response Bytes per Second (Throughput) graphs during test execution using the online monitors and after test execution using the Analysis. You view the Component Breakdown graph after test execution using the Analysis.

Advanced Web run-time options:

File and line in automatic transaction names: Creates unique transaction names for automatic transactions by adding file name and line number to the transaction name (enabled by default).

This option places additional information in the log file, and therefore requires more memory.

Non-critical item errors as warnings: This option returns a warning status for a function which failed on an item that is not critical for load testing, such as an image or Java applet that failed to download. This option is enabled by default. If you want a certain warning to be considered an error and fail your test, you can disable this option.

Save a local copy of all snapshot resources during replay: Instructs VuGen to save the snapshot resources to files on the local machine. This feature lets the Run-Time viewer create snapshots more accurately and display them quicker.

Best Practice:

·          The “Checks” have been left unselected, as normally we do not have any checks in our scripts unless specified by customer.

·          “Hits per second and HTTP codes” and “Response bytes per second” options are checked, which help us to do better analysis.

·          In the Advanced tab, we have checked the following three options:

1) “File and line in automatic transaction names”, because it helps to give each transaction name uniquely, which helps us in analysis to avoid any confusion.

2) “Non-critical item errors as warnings”: This avoids the failure of tests due to unimportant items.

3) “Save a local copy of all snapshot resources during replay”: This helps to run tests fast as the snapshots are stored locally.

Additional Options for Internet Preferences:

DNS caching: Instructs the Vuser to save a host’s IP addresses to a cache after resolving its value from the Domain Name Server. This saves time in subsequent calls to the same server. In situations where the IP address changes, as with certain load balancing techniques, be sure to disable this option to prevent Vuser from using the value in the cache. (enabled by default)

HTTP version: Specifies which version HTTP to use: version 1.0 or 1.1. This information is included in the HTTP request header whenever a Vuser sends a request to a Web server. The default is HTTP 1.1.

Keep-Alive HTTP connections: Keep-alive is a term used for an HTTP extension that allows persistent or continuous connections. These long-lived HTTP sessions allow multiple requests to be sent over the same TCP connection. This improves the performance of the Web server and clients. The keep-alive option works only with Web servers that support keep-alive connections. This setting specifies that all Vusers that run the Vuser script have keep alive HTTP connections enabled. (Yes by default)

Step timeout caused by resources is a warning: Issues a warning instead of an error when a timeout occurs due to a resource that did not load within the timeout interval. For non-resources, VuGen always issues an error. (No by default)

Parse HTML content-type: When expecting HTML, parse the response only when it is the specified content-type: HTML, text\html, TEXT any text, or ANY, any content-type. Note that text/xml is not parsed as HTML. The default is TEXT.

Accept-Language request header: Provides a comma-separated list of accepted languages. For example, en-us, and so forth.

HTTP-request Receive/Connect Timeout (seconds): The time, in seconds, that a Vuser will wait for the connection of a specific HTTP request within a step before aborting. Timeouts provide an opportunity for the server to stabilize and respond to the user. The default value is 120 seconds. The timeout settings are primarily for advanced users who have determined that acceptable timeout values should be different for their environment. The default settings should be sufficient in most cases. If the server does not respond in a reasonable amount of time, check for other connection-related issues, rather than setting a very long timeout, which could cause the scripts to wait unnecessarily.

Step download timeout (seconds): The time that the Vuser will wait before aborting a step in the script. This option can be used to emulate user behaviour of not waiting for more than x seconds for a page.

response. If the size of the data is larger than the specified size, the server will send the data in chunks, increasing the overhead of the system. When running multiple Vusers from the Controller, every Vuser uses its own network buffer.

Best Practice:

·         • “DNS Caching” is given value “Yes”.

·         • “Keep-Alive HTTP Connections” is given value “Yes”.

·         • We have kept the timeout for step download as 120 seconds because if we can’t download something in 120sec(2min), then it definitely needs to be tuned to give better performance. Anyhow in case of any special case, we can set the maximum values of these timeouts as follows:

1) Connect/Receive timeout -> 1000 seconds

2) Step download timeout -> 32000 seconds

Download filters:

     You can specify the Web sites from which Vusers should download resources during replay. You can indicate either the sites to exclude or the sites to include. You control the allowed or disallowed sources, by specifying a URL, host name, or host suffix name.

Content Checks:

   VuGen’s Content Check mechanism allows you to check the contents of a page for a specific string. This is useful for detecting non-standard errors. In normal operations, when your application server fails, the browser displays a generic HTTP error page indicating the nature of the error. The standard

error pages are recognized by VuGen and treated as errors, causing the script to fail. Some application servers, however, issue their own error pages that are not detected by VuGen as error pages. The page is sent by the server and it contains a formatted text string, stating that an error occurred.