Sunday, September 13, 2009

Configuring Run time settings

General – Run Logic:
This lets you control the number of iterations. In simple terms it will decide how many times the vuser has to run / execute.


General – Pacing: This lets you decide how the different iterations have to run, how to control the time between the iterations.


As soon as the previous iteration ends:
If you choose this setting the next iteration begins immediately after the previous iteration ends.

After the previous iteration ends with a fixed or random delay of:

  • New iteration is started after fixed delay of x secs only after the previous iteration ends.
  • New iteration is started after random delay of x secs only after the previous iteration ends. The range of the random delay can be chosen.

At fixed or random intervals, every ... [to ...] seconds:

New Iteration begins every x seconds or at random rate. Each scheduled iteration will only begin when the previous iteration is complete. For example, assume that you specify to start a new iteration every four seconds:

  • If the first iteration takes three seconds, the Vuser waits one second.
  • If the first iteration takes two seconds to complete, the Vuser waits two seconds.
  • If the first iteration takes 8 seconds to complete, the second iteration will start 8 seconds after the first iteration began. VuGen displays a message in the Execution Log to indicate that the iteration pacing could not be achieved.

See the log below:



Log:
Log files are very much required for debugging and correlation. Turning on the logs till you develop and fix your script helps you a lot. Log contains all the requests and responses made between client and the server.This is stored in a file called output.txt. You can either choose standard or extended log depending on how much information you want to log to output.You can enable and disable logging as and when required. When you have clean working script and running in the controller for volume /stress or load test its better to disable the logging .You can enable logging only when errors occurs.When you choose this you can set the size of log cache
Standard Log:
Creates a standard log of functions and messages sent during script execution to use for debugging
Extended Log:
Creates an extended log, including warnings and other messages. You can specify which additional information should be added to the extended log using the Extended log options:
  • Parameter substitution: This option will log all parameters associted with the script along with their values.
  • Data returned by server: This option will log all of the data returned by the server.
  • Advanced trace: This option will log all of the functions and messages sent by the Vuser during the session. This option is useful when you debug a Vuser script.

Note:To get extended log for a section of you script during execution you should use lr_set_debug_message function to set the Extended log. You must call the function again to specify what type of extended mode (Parameter, Result Data, or Full Trace). Return to the Standard log mode by calling lr_set_debug_message,


Think Time:

This allows you to Ignore think time or replay think time. Think time in simple words means wait, wait for the specified time that has been defined in the script. Think time is very important in performance testing to emulate a real user. Consider an example where real user is checking mails, there might be some real fast user who logs into mail, checks mail. There might be some slow user who logs into mail, does wait or think before he checks mails. So in these kind of situations think times and pacing comes handy for emulating real users. To tell Vuser script to hold execution for some time we use think times.

Ignore Think time:

This completely ignores the think time even if a think time statement is recorded in the script.

Replay Think time:

As Recorded: Choosing this option wil make the vuser script wait for the specified think time in the script which is inserted either by recording or manually after recording. lr_think_time(5);

  • Multiply recorded think time by: This option lets you multiply the think time present in the script by the value you specify. If you increase or decrease it. This is pretty straight forward.
  • Use random percentage of the recorded think time:This option lets you choose the range of percentage that will be applied on the think time present in the script. For example, if the think time argument is 2, and you specify a minimum of 50% and a maximum of 150%, the lowest think time can be one (50%) and the highest value three (150%).
  • Limit think time to: This option will Limit the maximum think time's value to the value specified in this option.

Error Handling :

  • Continue on error: Choosing this option lets the script continue execution even if it encounters any errors. Vuser will exit if you enable this option.
  • Fail open transactions on lr_error_message: Choosing this option will make transaction fail, if lr_error_message is placed inside the transaction. This is done using if statement when condition is met. See the ex below:

if (atoi(lr_eval_string("{rCount}")) == 0)

{ lr_error_message("s02_search failed for %s", lr_eval_string("{Id}"));

lr_end_transaction("search", LR_FAIL);

lr_exit( LR_EXIT_ACTION_AND_CONTINUE,LR_FAIL );

return(0); )

Generate Snapshot on Error:

This is pretty straight forward. Choosing this option generates a snapshot when an error occurs. To view the snapshot goto the Vuser Log and double-click on the line at which the error occurred.

Multithreading:

Vuser can be ran as thread or processor. Its always advantageous to run Vuser as thread as more number of vusers can be run per loadgenerator. Only Thread Safe protocols should be ran as threads.Note: The following protocols are not threadsafe: Sybase-Ctlib, Sybase-Dblib, Informix, Tuxedo, and PeopleSoft-Tuxedo.Controller uses a program called mdrv.exe to run Vusers. Lets see the difference between running vusers as thread and process:

Process: If you run as process mdrv.exe is launched into the memory repeatedly for every instance of Vuser. Loading mdrv.exe again and again utilises large amount of RAM and other system resources. This limits the vusers that can be run on a loadgenerator.

Thread: If you run Vuser as thread, once instance of mdrv.exe for every 50 Vuser. 50 Vuser is default setting. Each vuser runs as thread and these share memory segments of the parent driver. Re-loading of mrdv.exe again and again for every vuser is not required.Hence it saves utilization of RAM and other system resources. So more vusers can be run on loadgenerator compared to Process.

Automatic Transactions:

Define each action as transaction:

If you check this option each action is considered as a transaction along with the manually transactions you have inserted.

Define each step as transaction:

The Web_url’s, web_submit statements are considered as transactions and is displayed in the controller during executions. Its always better to have your own transactions manually inserted.


Browser Properties:

When Vuser run the script, it makes a request to the server. The request contains http header, resource name, protocol version. Vuser header also includes the type of browser details.Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; InfoPath.1)The information is what sent along with header. You can infact change the browser type that you may want vuser to use when running script.

Simulate Browser Cache:

Browser cache is used to store the resources accessed frequently and this reduces the time connected to the network. It is not required for the vuser to connect and request resource from the server when the same is available in the cache. If you consider in real time scenario some user may have enabled browser cache and some may not, so you can either choose or disable this option when running your scripts. When running multiple Vusers, every Vuser uses its own cache and retrieves resources from the cache.

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. This option brings up the most recent version of the page, but also generates more traffic during the scenario execution.

Download non-HTML resources:

In real time when a user access a site, the page is available with all contents along with the graphic images if any. Download of the page to the user client machine is done when all these resources are downloaded. So if you want Vuser to emulate this kind of scenario you can check this option. Vuser will load all images when accessing a web page during replay. Therefore, enable this option if you are trying to test the entire system, including end-user time like a real time scenario or real user.Note: Disable this option if you experience discrepancies in image checks, since some images vary each time you access a Web page (for example, advertiser banners).

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.


Checks:

We have 2 checkpoints i.e text and image check point. Using checkpoints along with if statements are very important in tracking the script executions and failures. Text checkpoint checks whether particualar text is present on the particular page and image checkpoint checks for the image present. These check statements are executed during the script run, and they track the resoponse sent from the server to check the same.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.

Generate Web Performance Graphs:

This option is useful when you want to generate graphs related to hits/sec, response/sec and pages/sec. Data required to display these graphs are captured during executions and displayed using online monitors. You can also display or get these metrics after the run using the analysis tool. Select the types of graph data for the Vuser to collect. Note: If you do not use the Web performance graphs, disable these options to save memory.

Advanced Web Run-Time Options:

WinInet Replay (instead of Sockets): Instructs VuGen to use the WinInet replay engine. VuGen has two HTTP replay engines: Sockets-based (default) or WinInet based. The WinInet is the engine used by Internet Explorer and it supports all of the features incorporated into the IE browser. The limitations of the WinInet replay engine are that it is not scalable, nor does it support UNIX. In addition, when working with threads, the WinInet engine does not accurately emulate the modem speed and number of connections. VuGen's proprietary sockets-based replay is a lighter engine that is scalable for load testing. It is also accurate when working with threads. The limitation of the sockets-based engine is that it does not support SOCKS proxy. If you are recording in that type of environment, use the WinInet replay engine.

File and line in automatic transaction names:

If you disable the automatic transactions option and check this option too then Unique transaction names are created by adding file name and line number to the transaction name.

Note: 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. You can set a content-type to be critical by adding it to the list of Non-Resources. For more information, see Specifying Non-Resource Content Types.

Save snapshot resources locally:

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.


Lets discuss few options which are important:

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. HTTP 1.1 supports the following features:

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 (enabled 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 issues an error (disabled by default).

HTTP-request 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 (default value is 120 seconds). Note that this timeout also applies to the time the Vuser will wait for a WAP connection, initiated by the wap_connect function.

HTTP-request Receive Timeout (seconds):

The time, in seconds, that a Vuser will wait to receive the response of a specific HTTP request within a step before aborting. Timeouts provide an opportunity for the server to stabilize and respond to the user (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 a user behavior of not waiting for more than x seconds for a ಪೇಜ್


This options lets you choose from which URL/ Website vuser has to download the resouce from. You can also put the list of URL’s in the exclude resource, when you do so Vuser doesn’t donload’s resources from all sites except from those in the exclude list. VuGen filters out resources from all Web sites except for those in the Include list. The filter type available are URL, HOST, HOST-Suffix.

Note: The run time settings chosen for running a script are displayed in the replay log at the beginning.

No comments:

Post a Comment