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.
