Performance

-1-

Performance
TABLE OF CONTENT Performance Testing:................................................................................................................................... 3 Pre-requisites for Performance Testing................................................................................................. 3 Load Tests:.................................................................................................................................................... 4 Why we need to do Load Tests? ............................................................................................................. 4 Stress Tests:................................................................................................................................................... 4 Focus of stress test ................................................................................................................................... 5 Soak Tests: (Also Known as Endurance Testing) ..................................................................................... 5 Volume Tests: ............................................................................................................................................... 5 Some of the Tools for Performance Testing:.............................................................................................. 5 Apache JMeter.............................................................................................................................................. 5 Seagull ........................................................................................................................................................... 6 WebLOAD .................................................................................................................................................... 6 Rational Performance Tester ...................................................................................................................... 6 Description: .............................................................................................................................................. 6 LoadRunner .................................................................................................................................................. 6 Real Time Scenario: ..................................................................................................................................... 6 Over View of LoadRunner: ......................................................................................................................... 7 Loadrunner Architecture ............................................................................................................................ 7 Virtual User Generator:............................................................................................................................... 7 Recording a Script ................................................................................................................................... 8 How to open Virtual User Generator? .............................................................................................. 8 Protocol Selection: .............................................................................................................................. 9 Recording Options ............................................................................................................................ 12 View the script: ................................................................................................................................. 18 Manual Correlation:......................................................................................................................... 21 Automatic Correlation: .................................................................................................................... 22 Parameterization: ............................................................................................................................. 23 Run Time Settings: ................................................................................................................................ 27 Definition for Run time setting:............................................................................................................ 27 Configuring Run-Time Settings: .......................................................................................................... 27 Configuring Run Logic Run-Time Settings (multi-action):...................................................... 28 Pacing Run-Time Settings ........................................................................................................... 31 Configuring the Log Run-Time Settings:................................................................................... 33 Configuring the Think Time Settings......................................................................................... 35 Configuring Miscellaneous Run-Time Settings ......................................................................... 37 Browser Emulation: ..................................................................................................................... 39 2. Controller ................................................................................................................................................ 41 LoadRunner Vuser Technology .................................................................................................. 42 Creating and Configuring Vusers: ............................................................................................. 43 Monitors........................................................................................................................................ 47 The following monitors are available through LoadRunner: ............................................................ 47 Vuser Status ........................................................................................................................................... 47 Transaction Monitor ............................................................................................................................. 47 Network Latency.................................................................................................................................... 47 Database Servers.................................................................................................................................... 50 The total number of bytes received from the client over Net8 ............................................ 52 The total number of current logons ....................................................................................... 52 3. Analysis ................................................................................................................................................ 56

-2-

Performance

Performance Testing:
Performance Tests are tests that determine end to end timing (benchmarking) of various time critical business processes and transactions, while the system is under low load, but with a production sized database. This sets best possible performance expectation under a given configuration of infrastructure. It also highlights very early in the testing process if changes need to be made before load testing should be undertaken. For example, a customer search may take 15 seconds in a full sized database if indexes had not been applied correctly, or if an SQL 'hint' was incorporated in a statement that had been optimized with a much smaller database. Such performance testing would highlight such a slow customer search transaction, which could be remediated prior to a full end to end load test. Pre-requisites for Performance Testing A performance test is not valid until the data in the system under test is realistic and the software and configuration is production like. The following table list pre-requisites for valid performance testing, along with tests that can be conducted before the pre-requisites are satisfied: Performance Test Pre-Requisites Comment Caveats on testing where Pre-requisites are not satisfied.
Lightweight transactions that do not require significant processing can be tested, but only substantial deviations from expected transaction response times should be reported.

Production Like Environment

Production Like Configuration

Production Like Version

Low bandwidth performance testing of high bandwidth transactions where communications processing contributes to most of the response time can be tested. Configuration of each component needs While system configuration will have less to be production like. impact on performance testing than load testing, only substantial deviations from expected transaction response times For example: Database configuration should be reported. and Operating System Configuration. Only major performance problems such as The version of software to be tested missing indexes and excessive should closely resemble the version to communications should be reported with a be used in production. version substantially different from the proposed production version. If clients will access the system over WAN, dial-up modems, DSL, ISDN, etc. then testing should be conducted using each communication access method. All relevant tables in the database need to be populated with a production like quantity with a realistic mix of data.

Performance tests need to be executed on the same specification equipment as production if the results are to have integrity.

Production Like Access

Only tests using production like access are valid.

Production Like Data

Low bandwidth performance testing of high bandwidth transactions where communications processing contributes to most of the response time can be tested.

-3-

Performance
Load Tests: Load Tests are end to end performance tests under anticipated production load. The objective such tests are to determine the response times for various time critical transactions and business processes and ensure that they are within documented expectations (or Service Level Agreements - SLAs). Load tests also measures the capability of an application to function correctly under load, by measuring transaction pass/fail/error rates. An important variation of the load test is the Network Sensitivity Test, which incorporates WAN segments into a load test as most applications are deployed beyond a single LAN. Load testing must be executed on todays production size database, and optionally with a projected database. If some database tables will be much larger in some months time, then Load testing should also be conducted against a projected database. It is important that such tests are repeatable, and give the same results for identical runs. They may need to be executed several times in the first year of wide scale deployment, to ensure that new releases and changes in database size do not push response times beyond prescribed SLAs. Why we need to do Load Tests? The failure of a mission-critical web application can be costly Assure performance and functionality under real-world conditions Locate and resolve potential problems before it hits on the users. We will get to know the maximum capacity the system can handle for an application We can decide whether we should go for Hardware upgrades or Performance tuning
Performance is Important

Stress Tests: Stress Tests determine the load under which a system fails, and how it fails. This is in contrast to Load Testing, which attempts to simulate anticipated load. It is important to know in advance if a stress situation will result in a catastrophic system failure, or if everything just goes really slow. There are various varieties of Stress Tests, including spike, stepped and gradual ramp-up tests. Catastrophic failures require restarting various infrastructures and contribute to downtime, a stress-full environment for support staff and managers, as well as possible financial losses. If a major performance bottleneck is reached, then the system performance will usually degrade to a point that is unsatisfactory, but performance should return to normal when the excessive load is removed. Before conducting a Stress Test, it is usually advisable to conduct targeted infrastructure tests on each of the key components in the system. A variation on targeted infrastructure tests would be to execute each one as a mini stress test.

-4-

Performance

Type of Application
Online Banking Marketing / Sales Application

Circumstances that could give rise to Stress levels of activity.

After an outage - when many clients have been waiting for access to the application to do their banking transactions. Very successful advertising campaign - or substantial error in advertising campaign that understates pricing details.

Focus of stress test In a stress event, it is most likely that many more connections will be requested per minute than under normal levels of expected peak activity. In many stress situations, the actions of each connected user will not be typical of actions observed under normal operating conditions. This is partly due to the slow response and partly due to the root cause of the stress event. Soak Tests: (Also Known as Endurance Testing) Soak testing is running a system at high levels of load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day (or night) than would be expected in a busy day, to identify any performance problems that appear after a large number of transactions have been executed. Also, it is possible that a system may stop working after a certain number of transactions have been processed due to memory leaks or other defects. Soak tests provide an opportunity to identify such defects, whereas load tests and stress tests may not find such problems due to their relatively short duration. Volume Tests: Volume Tests are often most appropriate to Messaging, Batch and Conversion processing type situations. In a Volume Test, there is often no such measure as Response time. Instead, there is usually a concept of Throughput. A key to effective volume testing is the identification of the relevant capacity drivers. A capacity driver is something that directly impacts on the total processing capacity. For a messaging system, a capacity driver may well be the size of messages being processed

Some of the Tools for Performance Testing:

Apache JMeter Description: Apache JMeter is a 100% pure Java desktop application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions. Apache JMeter may be used to test performance both on static and dynamic resources (files, Servlets, Perl scripts, Java Objects, Data Bases and Queries, FTP Servers and more).

-5-

Performance
Seagull Description: Seagull is a multi-protocol traffic generator test tool. Primary aimed at IMS protocols, Seagull is a powerful traffic generator for functional, load, endurance, stress and performance tests for almost any kind of protocol. Currently supports Diameter, XCAP over HTTP, TCAP (GSM Camel, MAP, and Win) protocols. WebLOAD Description: WebLOAD Open Source is a fully functional, commercial-grade performance testing product based on WebLOAD; WebLOAD provides a comprehensive and robust environment for load testing. This includes a full authoring environment for recording, editing and debugging test scripts, a highly efficient execution environment for defining load parameters (virtual users), running and monitoring the tests as well as reporting tools for analyzing and presenting test results. Rational Performance Tester Description: Rational Performance Tester is a performance testing tool for validating the scalability and reliability of complex e-business applications before deployment. It is one of a set of IBM Rational Software products for automated software testing. Rational Performance tester supports: Multi-user performance testing to validate web application scalability before deployment, with both a Windows and a Linux-based user interface GUI-based test creation flexible test customization with Java code load and performance testing of applications including web, Siebel 7.7 and SAP LoadRunner Description: Is a performance and load testing product by Hewlett-Packard (since it acquired Mercury Interactive in November 2006) for examining system behavior and performance, while generating actual load. LoadRunner can emulate hundreds or thousands of concurrent users to put the application through the rigors of real-life user loads, while collecting information from key infrastructure components (Web servers, database servers etc). The results can then be analyzed in detail, to explore the reasons for particular behavior. Real Time Scenario:
Consider the client-side application for an automated teller machine (ATM). Although each client is connected to a server, in total there may be hundreds of ATMs open to the public. There may be some peak times such as 10 a.m. Monday, the start of the work week during which the load is much higher than normal. In order to test such situations, it is not practical to have a test bed of hundreds of ATMs. So, given an ATM simulator and a computer system with LoadRunner, one can simulate a large number of users accessing the server simultaneously. Once activities have been defined, they are repeatable. After debugging a problem in the application, managers can check whether the problem persists by reproducing the same situation, with the same type of user interaction.

-6-

Performance

Over View of LoadRunner:

Loadrunner Architecture A simple architecture of LoadRunner is presented here. LoadRunner is divided up into 3 smaller applications: They are 1. Virtual User Generator (VuGen), 2. Controller 3. Analysis.

Virtual User Generator: The Virtual User Generator allows us to determine what actions we would like our Vusers, or virtual users, to perform within the application. We create scripts that generate a series of actions, such as logging on, navigating through the application, and exiting the program.enables the performance tester to play back and make modifications to the script as needed. Such modifications may include Parameterization, Correlation and Error handling. LoadRunner supports several protocols like Web HTML/HTTP, Remote Terminal Emulator, Oracle and Web Services. A protocol can be understood as a communication medium between the clients and the server. For example Web Online banking application uses HTML with some Java and Web services. LoadRunner is capable of recording scripts in both single and multiprotocol modes. During recording, VuGen records a tester's actions by routing data through a proxy. The type of proxy depends upon the protocol being used, and affects the form of the resulting script. For some protocols, various recording modes can be selected to further refine the form of the resulting script. For instance, there are two types of recording modes used in LoadRunner Web/HTTP testing: URL based, and HTML based.

-7-

Performance
Recording a Script How to open Virtual User Generator? Start -> All Programs -> Loadrunner -> Applications -> Virtual User Generator

The following start Page of Virtual User Generator gets opened. A new Script can be created using any of the following options: 1. File -> New 2. Click on New Vuser Script 3. Click on the New Script Icon

-8-

Performance
To open an already existing script, we can use any of the following three options: 1. File -> Open 2. Click on the Button Open Existing Script present in the section Open Script 3. Click on the icon Protocol Selection: Once you click on the New Script Button, the New Virtual User window opens with a list of protocol names. The Left pane contains three options: 1. New Single Protocol Script 2. New Multiple Protocol Script 3. New Script Recent Protocols The Right Pane contains the Category of Protocols in a Dropdown list and the corresponding protocols at the bottom .

Use the right protocol in order to record the script. Choosing an incorrect protocol will give a blank script. This document would explain about creating script for a Web Application using the HTTP/HTML protocol. The HTTP/HTML protocol can be selected from any of the following: 1. Category -> E-Business 2. Category -> Popular Protocols Once the protocol is selected, click on OK Button in the New Virtual User Window. The following Page opens.

-9-

Performance

To start recording an application, click on the Start Record ( The Start Recording Window opens as follows:

) Button.

- 10 -

Performance

Fill the details in the fields: 1. Application Type: This contains two data: 1. Internet Applications 2. Win32 Applications. 2. Program to Record: 1. Microsoft Internet Explorer, 2. Microsoft Outlook(Mail) 3. URL Address: Type the complete URL of the application to be recorded 4. Working Directory: The path of the Loadrunner gets populated. 5. Record into Action: Vuser_init, Action, Vuser_end
Script Section vuser_init Actions vuser_end Used when recording... a login to a server client activity a logoff procedure Is executed when... the Vuser is initialized (loaded) the Vuser is in "Running" status the Vuser finishes or is stopped

A script can have more than 1 action section. 6. Check the checkbox Record the Application Start Up if you need the application start up also to be recorded. 7. Options: Click on this box Options to view and set the Recording Options. The options chosen for demonstration are as follows:

Recording Options

- 11 -

Performance
Recording Options 1. Script: Select the language in which the script has to be generated.

2. Protocol: The protocol chosen in the previous step will be checked by default.

- 12 -

Performance
3. Recording: This allows us to specify the information to be recorded and which functions to be used when generating a script. HTML Mode - Generates a separate step for each user action. URL Mode - The URL-based script mode option instructs VuGen to record all browser requests and resources from the servers that were sent due to the user's actions. It automatically records every HTTP resource as URL steps (web_url statements).

HTML Mode: For browser applications without JavaScript, Larger Foot Print, The HTML mode is based on user actions, and the scripts contain functions that correspond directly to the action taken. Example: web_link (Enterprise Systems Performance", "Text=Enterprise Systems Performance ", "Snapshot=t4.inf", LAST); URL Mode: For non-browser applications, More Verbose, Prone to Correlation related issues. The URL mode is based on HTTP requests sent to the server as a result of user actions. Example: web_url (Enterprise Systems Performance", "URL=http://www.in.ibm.com/esp.html", "TargetFrame=", "Resource=0", "RecContentType=text/html", "Referer=http: // www.in.ibm.com/atc? . . . , "Snapshot=t4.inf", "Mode=URL", LAST);

- 13 -

Performance

Deciding on Recording Mode HTML Mode Intuitive and easy to understand Scalable Deciding on Modes
For browser applications, use HTML mode. For non-browser applications, use URL mode. Note: The option of mixing recording modes is available for very advanced users for performance tuning

URL Mode Not as intuitive as the HTML scripts More scalable and effective for creating a load test

4. Port Mapping: Select a server entry to enable/disable or update.

- 14 -

Performance
5. Advanced: Select the preferences as per the requirement.

6. Correlation: Click on the checkbox Enable Correlation during recording to enable correlation while recording. Else, leave the checkbox unchecked.

On setting the Recording Options, click OK in the Recording Options Window.

- 15 -

Performance
Next, click on OK in the Start Recording Window. The browser is invoked and the application corresponding to the URL entered in Recording Window gets opened. The Recording Toolbar will be floating over the application. Pause Recording

New Action

Rendezvous Point

Edit Recording

Text Check Stop Recording Record into Start/End Comment Transaction

Perform the actions to be recorded. To insert a new transaction, click on the button in the recording Toolbar. A small window named Start Transaction will be opened. Enter the Transaction name and click OK.

Similarly, to mark the end of a transaction, click on the End Transaction Button the name of the transaction in the End Transaction window.

and enter

To insert a new action, click on the and click OK.

icon in the recording toolbar and enter the action name

- 16 -

Performance

Once the recording is done, click on the Stop button in the recording toolbar. The recording summary page will be displayed as follows:

- 17 -

Performance
View the script: The recorded script can be viewed in 2 modes: 1. Tree View 2. Script View Tree view is an icon-based view that lists the actions of the Vuser as steps, while Script view is a text-based view that lists the actions of the Vuser as functions. Tree View To view the script in Tree view choose View > Tree View or click the Tree view button .

Script View: Script view is a text-based view that lists the actions of the Vuser as API functions. To view the script in Script view choose View > Script View or click the Script View button Tree View .

Test Tree

Snapshot

- 18 -

Performance
Script View

Editing the Script: Correlation: It is a method used by LoadRunner to handle Dynamic Contents. The examples of Dynamic content are ticket number in an online reservation system or a transaction id in an online banking application. These are named so, as these page components are dynamically created during every execution of the business process and always differ from the value generated in previous runs. These dynamic contents are a part of the server response. The LoadRunner usually identifies these on the basis of the left and right boundaries and ordinal identifiers. Suppose the values like time and date at time of recording never is same as run time and some times when working with web applications session ids. What we have to do is we have to use some functions whose o/p works as i/p of some other function and finally we get the value of dynamic variable which can have the value as o/p these functions. These o/p values will exactly matches with run time value of dynamic variables and test never fails due to dynamically changing variables. Correlation is used to obtain data which are unique for each run of the script and which are generated by nested queries. Automatic correlation is where we set some rules for correlation. It can be application server specific. Here values are replaced by data, which are created by these rules This correlation can be done in 2 ways. 1. First when u r not familiar with data items whom u have to correlate then u can use lrs search correlation option, lr list all dynamically changing variables of your test and lists then u can choose according to your requirement. Its called as Autocorrelation 2. Secondly if u r familiar with those whom you have to correlate directly u can correlate its called as Manual correlation. Example: System generated session ids URLs that change each time you access the Web page Fields (sometimes hidden) recorded during a form submission

- 19 -

Performance
Correlate the data Capture output value from one step Use captured value as input to another step Correlated data is data which is sent to the client from the server, and later sent back to the server by the client.
Step 2 - Request [Session ID = 22222]

Network
Step 1 [Session ID = 22222]

Client

Web Server

The following diagrams will give a clear idea about the need for correlation.
Client
Request 1 login(Gaurav, xyz)

Server

Response 1 Login Successful

A/C No.

A/C Type

Auth ID

Request 2 getAccountDetails(10011001, Savings, Response 2 Account Balance=xxx,

Script recorded using the User ID Gaurav and replayed using the same ID working fine (Before Correlation)

Client

Request 1 login(Amol, abc)

Server

Response 1 Login Successful AuthID=5678

A/C No.

A/C Type

Auth ID

Request 2 getAccountDetails(20011001, Savings, 1234)

Response 2 Not Authorized to view the details

Script recorded using the User ID Gaurav and replayed using the User ID Amol Error displayed (Before Correlation)

- 20 -

Performance

Client

Request 1 login(Amol, abc)

Server

Response 1 Login Successful AuthID=5678

Variable AuthID = findAuthID(Response1)

A/C No.

A/C Type

Auth ID

Request 2 getAccountDetails(20011001, Savings,{AuthID})

Response 2 Account Balance=xxx, CreditDebit

Script recorded using the User ID Gaurav and replayed using the User ID Amol Working fine (After Correlation)

Manual Correlation: Determine the value to capture Find the right and left text boundaries of the value to capture from the generation log. Find which occurrence of the text boundaries should be used Add a web_reg_save_param function to the script, above the step which requests the page with the value to capture 5. Add the parameter name, left boundary, right boundary, and occurrence to the function 6. Parameterize the dynamic value in the script every time it occurs 7. Verify correct execution 1. 2. 3. 4.

- 21 -

Performance

Left Boundary (LB)

Value to correlate

Right Boundary (RB)

So, the web_reg_save_param function for the correlation will be as follows: web_reg_save_param("inFlight", "LB=<input type=radio name=inFlight value=\"", "RB=\">", "ORD=ALL", LAST); Automatic Correlation: There are three types of automatic recording solutions Auto-Detect Correlation Rule-Based Correlation Correlating All Statements
Rule Name When to Use

Auto-detect Correlation Detect and correlate dynamic data for supported application servers Rule-Based When working with a non-supported application server whose context is known. Correlate All Blindly correlate all dynamic data.

- 22 -

Performance

Parameterization: Parameter is not a dynamic value captured from server response but it is something for which the user has predefined data values available. A parameter is a placeholder which re-places a recorded value in a Vuser script. At run time, a value from an external source is substituted for the parameter. Parameterize Input data During a run, VuGen replaces each parameter with a value from a data file or another external source, and inputs it to the Web application Parameterization The Process 1. Right click on the data to parameterize 2. Select Replace with a Parameter

3. The Select or Create Parameter dialog box opens.

4. Type a suitable name for the Parameter. 5. Click on the Properties button. The Parameter Properties window opens.

- 23 -

Performance

6. Select a Parameter Type (File for text fields like User ID, Password, etc. Date for date fields). 7. Click Create Table.

8. Click OK. 9. Select other options.

- 24 -

Performance

10. 11. 12. 13.

Click Close. Click OK in the Select or Create Parameter window. The script will display {User_ID} in pink color in the place of the value jojo In the script, Right-click the parameter name and select Replace More Occurrences to replace the data by the parameter name.

To parameterize password field, use the following options:

In the Properties window, select the file as User_ID.dat itself and click on Add column.

Click OK.

- 25 -

Performance

Since the Password should be selected from the same row as the User ID(each user ID will have a unique Password), the option Select next row: Same line as User ID is chosen. Click Close. Click OK. The value bean will be replaced by the parameter {Password}.Similarly parameterize all the input data. Data Access Method: Description of the options Select Next Row & Update value on 1. Select Next Row: Select next row instructs LoadRunner in what order to use data from the file (data source). The 4 options available in this field are: Sequential Selects the data sequentially row by row. Random Rows are selected randomly at run time. Uniqueness is not guaranteed. Unique Data are selected uniquely. Each Vuser has a block of rows for its exclusive use. Same line as <parameter> - Used for those data which are dependent on another data. E.g. password is dependent on the user ID. 2. Update Value on: Each Iteration Updates the value of the parameter once per iteration. Each Occurrence - Updates the value of the parameter once per occurrence of the parameter in the script.

- 26 -

Performance
Once - Updates the value of the parameter once.

Run Time Settings:

Definition for Run time setting: The testing (scenario) will not able to find the problem residing in the application or problem residing on OS level/hardware, which will not and nailing down the root cause of the problem. The run time setting able to find like think time between the transaction or enabling the caching (application level setting) for application will improve or degrade the application response time Before applying or setting the runtime setting User should have the understanding of the application he /she is going to test/use (scenario) and what is the goal of the scenario and the purpose of running the scenario. This understanding help user to correctly use and apply the correct run time setting in the scenario and find the correct response time of the application. After you record a Vuser script, you can configure its run-time settings. The Run-time settings define the way that the script runs. These settings are Stored in the file default.cfg, located in the Vuser script directory. Run-time settings are applied to Vusers when you run a script using VuGen or the Controller. Configuring Run-Time Settings: After you record a Vuser script, you configure the run-time settings for the script. These settings specify how the script behaves when it runs. About Run-Time Settings Configuring Run Logic Run-Time Settings (multi-action) Pacing Run-Time Settings Configuring Pacing Run-Time Settings (multi-action) Setting Pacing and Run Logic Options (single action) Configuring the Log Run-Time Settings Configuring the Think Time Settings Configuring Miscellaneous Run-Time Settings

Configuring run-time settings allows you to emulate different kinds of user activity. For example, you could emulate a user who responds immediately to output from the server, or a user who stops and thinks before each response. You can also configure the run-time settings to specify how many times the Vuser should repeat its set of actions. You use the Run-Time Settings dialog box to display and configure the runtime settings tree. You can open these settings in one of the following ways: Click the Run-Time Settings button on the VuGen toolbar. Press the keyboard shortcut key F4. Choose Vuser > Run-Time Settings.

- 27 -

Performance
You can also modify the run-time settings from the LoadRunner Controller. Click the Design tab and click the Run-Time Settings button.
Note: Vuser scripts have individual run-time setting defaults for VuGen and the Controller, to support the debugging environment of VuGen and the load testing environment of the Controller.

These are the default settings for Vuser scripts in VuGen and the Controller: Think Time: Off in VuGen and replay as recorded in the Controller. Log: Standard in VuGen and off in the Controller. Download non-HTML resources: Enabled in VuGen and the Controller. The General run-time settings, apply to all types of Vuser scripts. They include: Run Logic (Iterations) Pacing Log Think Time Miscellaneous For protocols that do NOT support multiple actions, such as WinSocket and Database (Oracle 2tier, Sybase, MSSQL, etc.), the Iteration and Pacing options are both handled from the Pacing tab. Many protocols have additional run-time settings. For information about the specific run-time Configuring Run Logic Run-Time Settings (multi-action): The following section only applies to protocols that work with multiple actions. If the Run Logic node exists under the run-time settings, it is a multiple action protocol. 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. Open the Run-Time Settings and select the General: Run Logic node

- 28 -

Performance

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 Controllers 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 much iteration 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 independentlyits 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. Weighting: For action blocks running their actions randomly, you can set the weight or percentage of each action within a block. Creating Action Blocks Action blocks are groups of actions within the Vuser script. You can create separate action blocks for groups of actions, adding the same action to several blocks. You can instruct VuGen to execute action blocks or individual actions sequentially or randomly. In the default sequential mode, the Vuser executes the blocks or actions in the order in which they appear in the iteration

- 29 -

Performance
tree view. In the following example, Block0 performs a deposit, Block1 performs a transfer, and Block2 submits a balance request. The Login and Logout actions are common to the three blocks.

To configure actions and action blocks: Create all of the desired actions through recording or programming. Open the Run-Time setting. Select the General: Run Logic node. Add a new action block. Click Insert Block. VuGen inserts a new Action block at the insertion point with the next available index (Block0, Block1, and Block2). Add actions to the block. Click Insert Action. The Select Actions list opens.

Select an action to add to the block and click OK. VuGen inserts a new action into the current block or section. Repeat step 3 for each action you want to add to the block. To remove an action or an action block, select it and click Delete. Click Move Up or Move Down to modify an items position. Click Properties to set the number of iterations and run logic of the actions. The Run Properties dialog opens.

Select Sequential or Random from the Run Logic list, indicating to VuGen whether to run the actions sequentially or randomly. Specify the number of iterations in the Iterations box. Note that if you define parameters within the action block, and you instruct VuGen to update their values each iteration, it refers to the global iterationnot the individual block iteration. Click

- 30 -

Performance
OK. For blocks with Random run logic, set the weighting of each action. Right click an action and choose Properties. The Action Properties dialog opens.

Specify the desired percent for the selected block or action. In the Random Percents box, specify a percentage for the current action. The sum of all percentages must equal 100.Repeat the above steps for each element whose properties you want to set. Pacing Run-Time Settings 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. after the previous iteration ends with a fixed/random delay of At fixed/random intervals, every / to second.

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 when you run the script. At fixed or random intervals, every [to ] seconds: You specify the time between iterationeither 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 iterations will only begin when the previous iteration is complete. 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 when you run the script. 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. LoadRunner displays a message in the Execution Log to indicate that the iteration pacing could not be achieved. Configuring Pacing Run-Time Settings (multi-action) you use the Pacing options to pace your actions by setting the time intervals between iterations.

- 31 -

Performance

To set the pacing between iterations: Open the Run-Time Settings and select the General: Pacing node.

In the Start New Iteration section, select one of the following options: As soon as the previous iteration ends After the previous iteration ends At fixed or random intervals For the After the previous iteration ends option: Select a delay type: fixed or random. Specify a value for fixed, or a range of values for the random delay. For the At intervals option: Select an interval type: fixed or random. Specify a value for fixed, or a range of values for the random interval. Click OK. Setting Pacing and Run Logic Options (single action) If there is a Pacing node and not a Run Logic node under the General run-time settings, it is a single action protocol. You can instruct a Vuser to repeat the Action 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. If you specify scenario duration in the Controllers Scheduling settings, then 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 much iteration as required in five minutes, even if the run-time settings specify only one iteration. To set the iteration and pacing preferences:

- 32 -

Performance
Click the Run-Time Settings button on the VuGen toolbar or select Vuser >Run-Time Settings. Click the Pacing node to display the iteration and pacing options.

Specify the number of iterations in the Iteration Count box. LoadRunner repeats all of the Actions the specified number of times. In the Start New Iteration section, select one of the following options: As soon as the previous iteration ends After the previous iteration ends At fixed or random intervals For the After the previous iteration ends option: Select a delay type: fixed or random. Specify a value for fixed, or a range of values for the random delay. For the At intervals option: Select a interval type: fixed or random. Specify a value for fixed, or a range of values for the random interval. Click OK. Configuring the Log Run-Time Settings: During execution, Vusers log information about themselves and their communication with the server. In a Windows environment, this information is stored in a file called output.txt in the script directory. In UNIX environments, the information is directed to the standard output. The log information is useful for debugging purposes. The Log run-time settings let you determine how much information is logged to the output. You can select Standard or Extended log, or you can disable logging completely. Disabling the log is useful when working with many Vusers. If you have tens or hundreds of Vusers logging their run-time information to disk, the system may work slower than normal. During development, enable logging so that you will have information about the replay. You should only disable logging after verifying that the script is functional.

- 33 -

Performance

You can program a Vuser script to send messages to the output by using the lr_error_message and lr_output_message functions. Click the Run-Time Settings button on select Vuser > Run-Time Settings to display the RunTime Settings dialog box. Select the General: Log node to display the log options.

Enable Logging: This option enables automatic logging during replayVuGen writes log messages that you can view in the Execution log. This option only affects automatic logging and log messages issued through lr_log_message. Messages sent manually, using lr_message, lr_output_message, and lr_error_message, are still issued. Log Options: The Log run-time setting allows 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. If you choose to send messages only when errors occur, also known as JIT, (Just in Time) messaging, you can set an advanced option, indicating the size of the log cache. Setting the Log Detail Level: You can specify the type of information that is logged, or you can disable logging altogether. If you set Error Handling to Continue on error in the General Run-Time Settings folder, error messages are still sent to the Output window. If you modify the scripts Log Detail Level, the behavior of the lr_message, lr_output_message, and lr_log_message functions will not changethey will continue to send messages. Standard Log:

- 34 -

Performance
Creates a standard log of functions and messages sent during script execution to use for debugging. Disable this option for large load testing scenarios. If the logging level is set to Standard, the logging mode is automatically set to JIT logging when adding it to a scenario. 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. For more information on parameters. 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. The degree to which VuGen logs events (Standard, Parameter substitution, and so forth) is also known as the message class. There are five message classes: Brief, Extended, Parameters, Result Data, and Full Trace. You can manually set the message class within your script using the lr_set_debug_message function. This is useful if you to want to receive debug information about a small section of the script only. Setting the Log Cache Size: The Advanced options for the Log Run-Time settings let you indicate the size of the log cache. The log cache stores raw data about the test execution, to make it available should an error occur. When the contents of the cache exceed the specified size, it deletes the oldest items. The default size is 1KB. The following is the sequence of the logging: 1. You indicate to VuGen to log messages only when an error occurs, by selecting Send messages only when an error occurs. 2. VuGen stores information about the test execution in the log cache without writing it to a file. If this information exceeds 1 KB, it overwrites the oldest data. The Execution Log tab also remains empty, since it is a dump of the log files contents. 3. When an error occurs (either an internal error or a programmed error using lr_error_message), VuGen places the contents of the cache into the log file and Execution Log tab. This allows you to see the events that led up to the error. When an error occurs and VuGen dumps its stored cache into the log file, the actual file size will be greater than the cache size. For example, if your cache size is 1KB, the log file size may be 50 KB. This is normal and only reflects the overhead required for formatting the raw data into meaningful sentences. Configuring the Think Time Settings Vuser think time emulates the time that a real user waits between actions. For example, when a user receives data from a server, the user may wait several seconds to review the data before responding. This delay is known as the think time. VuGen uses lr_think_time functions to record think time values into your Vuser scripts. The following recorded function indicates that the user waited 8 seconds before performing the next action: lr_think_time (8);

- 35 -

Performance
When you run the Vuser script and the Vuser encounters the above lr_think_time statement, by default, the Vuser waits 8 seconds before performing the next action. You can use the Think Time run-time settings to influence how the Vuser uses the recorded think time when you run the Script. Click the Run-Time Settings button on the VuGen toolbar or select Vuser >Run-Time Settings. Select the General: Think Time node to display the Think Time options:

Think Time Options: By default, when you run a Vuser script, the Vuser uses the think time values that were recorded into the script during the recording session. VuGen allows you to use the recorded think time, ignore it, or use a value related to the recorded time: Is the idle time of user with the web application between one request and next request?

Ignore think time: Ignore the recorded think timereplay 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:

- 36 -

Performance
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%). Limit think time to: Limit the think times maximum value. Configuring Miscellaneous Run-Time Settings You can set the following miscellaneous run-time options for a Vuser script: Error Handling Multithreading Automatic Transactions Click the Run-Time Settings button or select Vuser > Run-Time Settings to display the Run-Time Settings dialog box. Select the General: Miscellaneous node from the tree in the left pane.

The Miscellaneous settings apply to all Vuser script types. Error Handling: Continue on Error:

- 37 -

Performance
This setting instructs Vusers to continue script execution when an error occurs. option is disabled by default. This

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. The lr_error_message function is issued through programmed If statement, when a certain condition is met.

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. Error Handling for Database Vusers When working with database protocols (LRD), you can control error handling for a specific segment of a script. To mark a segment, enclose it with LRD_ON_ERROR_CONTINUE and LRD_ON_ERROR_EXIT statements. The Vuser applies the new error setting to the whole segment. If you specify Continue on Error, VuGen issues a messages indicating that it encountered an error and is ignoring it. For example, if you enable the Continue on Error feature and the Vuser encounters an error during replay of the following script segment, it continues executing the script. To instruct the Vuser to continue on error for the entire script except for a specific segment, select the Continue on Error option and enclose the segment with LRD_ON_ERROR_EXIT and LRD_ON_ERROR_CONTINUE statements In addition to the LRD_ON_ERROR statements, you can control error handling using severity levels. LRD_ON_ERROR statements detect all types of errorsdatabase related, invalid parameters, etc. If you want the Vuser to terminate only when a database operation error occurs (Error Code 2009), you can set a functions severity level. All functions that perform a database operation use severity levels, indicated by the function's final parameter, miDBErrorSeverity.VuGen supports the following severity levels:

For example, if the following database statement fails (e.g. the table does not exist), the script execution terminates.
lrd_stmt(Csr1, "insert into EMP values (Smith,301)\n", -1, 1, 1, 0);

To instruct VuGen to continue script execution, even when a database operation error occurs, change the statements severity level from 0 to 1.
lrd_stmt(Csr1, "insert into EMP values (Smith,301)\n", -1, 1, 1, 1); Note: When you enable Continue on Error, it overrides the 0 severity level; script execution continues even when database errors occur. However, if you disable Continue on Error, but you specify a severity level of 1, script execution continues when database errors occur.

Multithreading

- 38 -

Performance
Vusers support multithread environments. The primary advantage of a multithread environment is the ability to run more Vusers per load generator. Only threadsafe protocols should be run as threads. The following protocols are not threadsafe: Sybase-Ctlib, SybaseDblib, Informix, Tuxedo, and PeopleSoft-Tuxedo. To enable multithreading, click Run Vuser as a thread. To disable multithreading, click Run each Vuser as a process. Run Vuser as a process. The Controller uses a driver program (e.g., mdrv.exe, 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) If you disable automatic transactions, you can still insert transactions manually during and after recording. For more information on manually inserting transactions, see Chapter 6, Enhancing Vuser Scripts. Setting Proxy Run-Time Settings. The following section discusses the steps required for configuring the proxy Run-Time settings. Browser Emulation: Browser Emulation node in the Run-Time Settings tree is to set the browser properties. Browser Properties You can set the browser properties in the following areas: User-Agent browser to be emulated Simulate browser cache Download non-HTML resources Simulate a new user as each iteration Whenever a Vuser sends a request to a Web server, the request always includes an HTTP header. The first line of text contains a verb (usually "GET" or "POST"), the resource name (for example "pclt/default.htm"), and the version of the protocol (for example "HTTP/1.0"). Subsequent lines contain "header information" in the form of an attribute name, a colon, and some value. The request ends with a blank line.

- 39 -

Performance
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 advanced options for caching and checking for newer resources User-Agent browser to be emulated

You can modify your Run-Time settings to match your browser settings for Internet Explorer: Browser Setting Every visit to the page Every time you start Internet Explorer Automatically Never Run-Time Setting Select Simulate Browser Cache and enable Check for newer versions of stored pages every visit to the page. Select Simulate Browser Cache only Select Simulate Browser Cache only Select Simulate Browser Cache and disable Check for newer versions of stored pages every visit to the page.

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. To define additional content types whose content you want to cache, click Advanced. (This increases the memory footprint of the virtual user.) This option is enabled by default. If you enable Simulate browser cache, but disable this option, VuGen nevertheless stores the graphic files.

- 40 -

Performance

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. Configure this option to match the settings in the browser that you wish to emulate. 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. Instructs VuGen to reset all HTTP contexts between iterations to their state 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 browsers 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 browsers cache, simulating a user who recently visited the page.

Cache URLs Requiring Content - Advanced The Advanced dialog box lets you specify the URL content types that you want to store in the cache. This dialog box is accessible from the Run-time Settings - Browser: Browser Emulation node. To add a content type: Enable the Specify URLs requiring content in addition to HTML page option. Click the plus sign to add additional content types, such as text/plain, text/xml, image/jpeg, and image/gif.Enter the content name in the text box. To remove a content type from the list, select it and click the minus sign. Setting Internet Preferences

2. Controller
Once a script is prepared in VuGen, it is run via the Controller. The Controller takes the scripts that we have made and runs them through a schedule that we set up. We tell the Controller how many Vusers to activate, when to activate them, and how to group the Vusers and keep track of them. For example, to run a test of 1000 users, we can use three or more machines with a LoadRunner agent installed on them. These machines are known as Load Generators because the actual load will be generated from them (Load Generators were previously known as "Injectors" - the

- 41 -

Performance
latter term is still widely used). Each run is configured with a scenario, which describes which scripts will run, when they will run, how many virtual users will run, and which Load Generators will be used for each script. The tester connects each script in the scenario to the name of a machine which is going to act as a Load Generator, and sets the number of virtual users to be run from that Load Generator. LoadRunner uses monitors during a load test to monitor the performance of individual components under load. Once a scenario is set and the run is completed, the result of the scenario can be viewed via the Analysis tool. Creating the Scenario A scenario describes the events that occur during a testing session. A scenario includes a list of machines on which Vusers run a list of scripts that the Vusers run, and a specified number of Vusers or Vuser groups that run during the scenario. You create scenarios using the LoadRunner Controller. Creating a Manual Scenario You create a scenario by defining Vuser groups to which you assign a quantity of individual Vusers, Vuser scripts, and load generators to run the scripts You can also create a scenario using the Percentage Mode, in which you define the total number of Vusers to be used in the scenario, and the load generator machines and percentage of the total number of Vusers to be assigned to each Vuser script. Creating a Goal-Oriented Scenario For Web tests, you can create a goal-oriented scenario, in which you define the goals you want your test to achieve. LoadRunner automatically builds a scenario for you, based on these goals. LoadRunner Vuser Technology On each Windows load generator, you install the Remote Agent Dispatcher (Process) and a LoadRunner Agent.

Terminology in LR Controller: Ramp Up: The no of Vusers should be increased with in the specified time. Ramp Down: The no of Vusers should be decreased with in the specified time. Scheduled Duration: The Duration time that the script should be executed. Remote Agent Dispatcher (Process): The Remote Agent Dispatcher (Process) enables the Controller to start applications on the load generator machine. Agent: The LoadRunner Agent enables the Controller and the load generator to communicate with each other. When you run a scenario, the Controller instructs the Remote Agent Dispatcher (Process) to launch the LoadRunner agent. The agent receives instructions

- 42 -

Performance
from the Controller to initialize, run, pause, and stop Vusers. At the same time, the agent also relays data on the status of the Vusers back to the Controller Creating and Configuring Vusers: Creating VUser groups Click the Add Group button on the right of the Scenario groups window. The Add Group dialog box opens. Enter a name for the Vuser group Specify the number of Vusers in the group

Select a load generator from the Load Generator Name list Select Add from the Load Generator Name list if the load required generator is not listed. Select a script from the script list Click OK to close the Add Group dialog box. The new group's properties appear in the Scenario Groups window Configuring VUsers in Vuser Groups

Select the Vuser group whos Vusers are to be modified, and click the Vusers button on the right of the Scenario Groups window. The Vusers dialog box opens. Can change the Script Can change the Load Generator Can Add Vusers to the group

- 43 -

Performance

Configuring Load Generators

Click the Generators button to open the Load Generator dialog box. Name, Status, Platform and Details of the Load Generators are displayed

Configuring Scripts:
Select the Vuser group whose script needs to be modified, and click the Details button on the

right of the Scenario Groups window

Run-Time Settings from the Controller shows the setting of VuGen. If these settings are

modified from the Controller, LoadRunner runs the script using the modified settings
Edit scripts by clicking on View Scripts

Scheduling a Scenario:
Can instruct LoadRunner to execute a scenario or Vuser group with a delay. The time duration of a scenario or Vuser group can be limited. The scenario or Vuser group

stops running after the elapse of this time.

Can stipulate how many Vusers LoadRunner runs within a certain time frame during a

scenario or Vuser group. Select the Scenario Scheduling option:

- 44 -

Performance
In the Ramp Up tab: Selecting Load all Virtual Users (Vusers) simultaneously will run all the Vusers at once. To gradually run the Vusers, select the number of Vusers to begin running concurrently and the amount of time LoadRunner has to wait between Vuser ramp ups.

To set the duration of the scenario, click the Duration tab. There are 3 choices 1. Run until completion 2. Specify the amount of time for which the scenario will run, once all the Vusers have been ramped up 3. Run indefinitely Selecting Initialize all Vusers before Ramp-Up, instructs LoadRunner to initialize Vusers before beginning to load them

Scheduling a Vuser group After creating a Vuser group, the groups script execution settings can be scheduled Vuser group Execution Settings The amount of time after the start of the scenario that the group must wait before it starts running The number of Vusers that will run within a specified period of time The amount of time the group will run Select Schedule By Group to set the schedule for the Vuser group. The options are similar to that of scheduling the scenario

- 45 -

Performance

Running the Scenario You emulate user load on the server by instructing multiple Vusers to perform tasks simultaneously. You can set the level of load by increasing and decreasing the number of Vusers that perform tasks at the same time. Before you run a scenario, you set the scenario configuration and scheduling. This determines how all the load generators and Vusers behave when you run the scenario. You can run the entire scenario, groups of Vusers (Vuser groups), or individual Vusers. While a scenario runs, LoadRunner measures and records the transactions that you defined in each Vuser script. You can also monitor your systems performance online Running a Scenario is of two types.
Can run all the Vusers and Vuser groups in a scenario OR Can run the specific Vuser groups and Vusers When running the entire scenario, LoadRunner does not begin running Vusers until

all of them have reached the ready state If individual groups or Vusers are run, LoadRunner runs the Vusers as soon as they reach the ready state Clicking the Start Scenario in the RUN tab of the Controller starts the execution of the Scenario Can Initialize, Stop, Pause and Reset Vuser groups Monitoring a Scenario

Monitoring a Scenario You can monitor scenario execution using the LoadRunner online run-time, transaction, system resource, Web resource, Web server resource, Web application server resource, database server resource, network delay, streaming media resource, firewall server resource, ERP server resource, and Java performance monitors. For more information, see Part IV, Monitoring a Scenario.

- 46 -

Performance

Monitors LoadRunner uses a suite of integrated performance monitors. It can be used to quickly isolate system bottlenecks with minimal impact on the system that is being tested. The suite consists of monitors for the network, application servers, web servers and database servers. These monitors are designed to accurately measure the performance of every single tier, server and component of the system. The following monitors are available through LoadRunner: 1. Vuser Status 2. Transaction Monitor 3. Network Latency 4. Web Servers 5. Database Server 6. Server Resources Vuser Status The Vuser Status monitor displays the current state of the Vusers (i.e. READY, RUNNING). No configuration is necessary for this monitor. Data is captured and displayed automatically. Transaction Monitor The Transaction monitor displays the transaction rate and response time during the scenario execution. No configuration is necessary for this monitor. Data is captured and displayed automatically. Network Latency

- 47 -

Performance
Network monitor can be used to determine whether the network is causing a delay. Network configuration is a primary factor in the performance of applications. A poorly designed network can slow client activity to unacceptable levels. To measure network performance, the network monitor sends packets of data across the network. When a packet returns, the monitor calculates the time it takes for the packet to go to the requested node and return. This time is the delay that appears on the Network Delay graph. To Configure Network Monitor: 1. First make sure that the controller is not running any scenario. 2. In the controller window, Go to Online Monitors tab 3. Select Monitors->Offline Monitors->Network Delay from the menu 4. Check Enable network delay monitoring checkbox from Network Monitoring Add button window and click on 5. Provide the origin address or host machine location and the destination address on the network path window 6. Click OK on network path window and on Network Monitoring window. 7. Network monitoring will start as soon as the scenario is executed.

Web Servers LoadRunner Web server monitor is useful in isolating web server performance bottlenecks Apache Monitor In order to monitor an Apache server, it is important to know the server statistics information URL. This fixed URL enables displaying performance data from a remote client. The URL should be in the following format:
http://<server_name/IP address>: port/server-status? auto (Example: http://stimpy:80/server-status?auto)

In order to activate the online monitor from the controller: 1. Enter Server name or IP address of the Apache server machine

- 48 -

Performance
2. Under server properties enter the port number, and URL (without server name the default is /server-status? auto) 3. Select counter measurement

Apache monitor counters

Microsoft Internet Information Server (MS IIS) IIS monitor is just an addition to Windows NT Performance Monitor. In order to provide this monitor, LR simply connects to PerfMon with pre-defined web service object filtering.
Note: To monitor IIS from outside the firewall, TCP port 139 needs to be opened.

To configure an IIS Monitor: 1. Go to Online Monitor tab and highlight IIS from the Monitor tree. 2. Select Monitor->Add Online Measurements and IIS Monitor window will pop up 3. In the Monitored Server Machines section of the IIS dialog box, click Add to enter the server name or IP address of the machine to be monitored. Select the platform on which the machine runs, and click OK. 4. In the Resource Measurements section of the IIS dialog box, select the measurements. 5. Select counters and instances. The instance is relevant only if multiple instances of the highlighted counter are running 6. Click Add to place the selected counter on the resource list. Add all the desired resources to the list and then click Close.

- 49 -

Performance
7. Click OK in the IIS dialog box to activate the monitor.

IIS monitor counters

Database Servers Microsoft SQL Server Monitor SQL Server monitor measures the standard NT system resources on the database server machine.
Note: To monitor SQL Server from outside the firewall, TCP port 139 needs to be opened.

To Configure SQL Server Monitoring: 1. Go to Online Monitor tab and highlight SQL Server from the Monitor tree. 2. Select Monitor->Add Online Measurements and SQL Server Monitor window will pop up 3. In the Monitored Server Machines section of the SQL Server dialog box, click Add to enter the server name or IP address of the machine to be monitored. Select the platform on which the machine runs, and click OK. 4. In the Resource Measurements section of the SQL Server dialog box, select the measurements. 5. Select a counter and instance. The instance is relevant only if multiple instances of the highlighted counter are running

- 50 -

Performance
6. Click Add to place the selected counter on the resource list. Add all the desired resources to the list and then click Close. 7. Click OK in the SQL Server dialog box to activate the monitor. SQL Server monitor.

SQL Server counters

Oracle Monitor The Oracle monitor measures information from Oracle V$ tables: Session statistics, (V$SESSTAT), and system statistics, (V$SYSSTAT). In order to view the information in the Oracle V$ tables, first set up the list of Oracle servers available to the client and configure the desired username/password/server combination. Before configuring Oracle Monitor in the Controller, the following environment needs to be setup: 1. 2. Install the Oracle client libraries on the Controller machine and make sure that the machine has database administrator privileges. Ensure that the registry on the Controller machine is updated for the version of Oracle that is being used and has the following key: HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE Check to see that the Oracle servers are up and running

3.

- 51 -

Performance
4. 5. Run SQL*Plus from the Controller and attempt to log in to the Oracle server(s) with the desired username/password/server combination. Type SELECT * FROM V$SYSSTAT to verify that the V$SYSSTAT table on the Oracle server can be viewed. Use similar queries to verify the other tables on the server(s). Make sure that the Oracle bin directory is in the search path.

Note: To monitor Oracle from outside the firewall, port(s) that need to be opened depends on the configuration of Oracle Server (tnsnames.ora file) To Configure Oracle Monitoring: 1. 2. 3. Go to the Online Monitor tab in the LoadRunnner Controller. Highlight Oracle from the Monitor tree. Select Monitor->Add Online Measurements. The Oracle Monitor window will pop up In the Monitored Server Machines section of the Oracle dialog box, click Add to enter the server name or IP address of the machine to be monitored. Select the platform on which the machine runs, and click OK. In the Resource Measurements section of the Oracle dialog box, select the desired counters for the measurement. The Oracle Logon dialog box opens. Enter login name, password, and Server name, and click OK. The Add Oracle Measurements dialog box opens. Select an object, measurement, and instance. The instance is relevant only if multiple instances of the highlighted measurements are running. See below for suggestion on which counters are useful. Click Add to place the selected measurement on the resource list. Add all the desired resources to the list and then click Close. Click OK in the Oracle dialog box to activate the monitor.

4. 5. 6.

7.

Some Metrics from V$SYSSTAT Table 1. CPU used by this session The amount of CPU time (in 10s of ms) used by a session between a user call started and ended. 2. Bytes received via SQL*Net from client The total number of bytes received from the client over Net8 3. Logons current The total number of current logons 4. Opens of replaced files The total number of files that needed to be reopened because they were no longer in the process file cache. 5. User calls The total number of user calls. 6. SQL*Net roundtrip to/from client

- 52 -

Performance
Total number of Net8 messages sent to and received from the client. 7. Bytes sent via SQL*Net to client The total number of bytes sent to the client from the foreground processes 8. Opened cursors current The total number of current open cursors. 9. DB block changes The total number of changes that were made to all blocks in the SGA that were part of an update or delete operation. 10. Total file opens The total number of file opens being performed by the instance

Windows NT/2000 Windows NT/2000 measurements correspond to the built-in counters available from the NT/2000 Performance Monitor.
Note: To monitor a remote NT machine that does not use NT domain security, the Controller machine needs to be authenticated on the remote NT server. To authenticate the Controller machine, create an account, or change the password of the account used to log on to the Controller so that it matches the password and user name used to log on to the remote monitored NT machine. When the remote NT machine requests another machines resources, it sends the logged-in user name and password of the machine requesting the resources.

Configuring UNIX Server Resources Section UNIX

UNIX Resources

- 53 -

Performance
UNIX measurements include the counters from the rstatd protocol: average load, collision rate, context switch rate, CPU utilization, incoming packets error rate, incoming packets rate, interrupt rate, outgoing packets error rate, outgoing packets rate, page-in rate, page-out rate, paging rate, swap-in rate, swap-out rate, system mode CPU utilization, and user mode CPU utilization.
Note: rstatd process needs to be started on all UNIX machines being monitored. Refer to UNIX man pages on how to start a rstatd process if not automatically started. Measurement Average load Collision rate Context switches rate CPU utilization Disk rate Incoming packets error rate Incoming packets rate Interrupt rate Outgoing packets errors rate Outgoing packets rate Page-in rate Page-out rate Paging rate Swap-in rate Swap-out rate System mode CPU utilization User mode CPU utilization Description Average number of processes simultaneously in Ready state during the last minute. Collisions per second detected on the Ethernet Number of switches between processes or threads per second Percent of time that the CPU is utilized Rate of disk transfers Errors per second while receiving Ethernet packets Incoming Ethernet packets per second Number of device interrupts per second Errors per second while sending Ethernet packets Outgoing Ethernet packets per second Number of pages read to physical memory per second Number of pages written to pagefiles(s) and removed from physical memory per second Number of pages read to physical memory or written to pagefile(s) per second Number of processes being swapped-in to memory per second Number of processes being swapped-out from memory per Second Percent of time that the CPU is utilized in system mode Percent of time that the CPU is utilized in user mode

Configuring Server Resources Monitor for both Windows NT/2000 and UNIX: 1. Go to Online Monitor tab and highlight Server Resources from the Monitor tree. 2. Select Monitor->Add Online Measurements. The Server Resources Monitor window will pop up. 3. In the Monitored Server Machines section of the Server Resources dialog box, click Add to enter the server name or IP address of the machine to be monitored. Select the platform (Windows or UNIX) on which the machine runs, and clicks OK 4. In the Resource Measurements section of the Server Resources dialog box, select the measurements. 5. Select a counter(s). 6. Click Add to place the selected counter on the resource list. Add all the desired resources to the list and then click Close. 7. Click OK in the Server Resources dialog box to activate the monitor.

Objectives of this Article

Understanding the results directory structure

- 54 -

Performance
Introduction to the Analysis tool Creating Analysis graphs Interpreting Analysis graphs

Results Directory Structure In results directory, LoadRunner creates a subdirectory using the results name specified All the data LoadRunner gathers is placed in that directory Every set of results contains general information about the scenario in a result file (.lrr) event (.eve) file. by us and an

During scenario execution, LoadRunner also gathers data from each Vuser and stores it in an event file _t_rep.eve and an output file output.txt LoadRunner creates a directory for each group in the scenario and a subdirectory for each Vuser

- 55 -

Performance

3. Analysis
This tool takes the completed scenario result and prepares the necessary graphs for the tester to view. Also, graphs can be merged to get a good picture of the performance. The tester can then make needed adjustments to the graph and prepare a LoadRunner report. The report, including all the necessary graphs, can be saved in several formats, including HTML and Microsoft Word format. The Analysis graphs helps to determine system performance and provides information about transactions and Vusers by combining results from several scenarios or merging several graphs into one. The Analysis is the utility that processes the gathered result information and generates graphs and reports The result file with an .lrr extension is the input to the Analysis tool An Analysis session contains at least one set of scenario results (lrr file)

Starting the Analysis: The Analysis can be started as an independent application or directly from the Controller

Analysis Summary Report:

- 56 -

Performance

Transaction summary Area:

Analysis graphs: The Analysis graphs are divided into the following categories: Vusers Errors Transactions Web Resources Web Page Breakdown User-Defined Data Points System Resources Network Monitor Firewalls Web Server Resources Web Application Server Resources Database Server Resources

- 57 -

Performance
Streaming Media ERP Server Resources Vuser Vuser graphs display information about Vuser states and other Vuser statistics Error Error graphs provide information about the errors that occurred during the scenario execution Transaction Transaction graphs and reports provide information about transaction performance and response time Web Resource These graphs provide information about the throughput, hits per second, HTTP responses per second, and downloaded pages per second for Web Vusers. System Resource These graphs show statistics relating to the system resources that were monitored during the scenario using the online monitor. Network Monitor Network Monitor graphs provide information about the network delays. Opening Analysis graphs: By default, LoadRunner displays only the Summary Report in the graph tree view Select Graph > Add Graph or click <New Graph> in the graph tree view This opens a New Graph dialog box Choose the required graph

Interpreting Analysis graphs: LoadRunner Analysis graphs present important information about the performance of your scenario. Using these graphs, Can identify and pinpoint bottlenecks in applications. Determine changes need to improve its performance.

- 58 -

Performance
Estimate the maximum load that server can handle. Find response time of transactions under varied load. Case Study #1 Analyzing Performance under Load

Case Study #2 Breaking down Trx Response time

Case Study #3 Web page breakdown graphs

- 59 -

Performance

Case Study #4 Identifying Network Problems

- 60 -

Performance
Case Study #5 Identifying Server Problems

Case Study #5 Identifying Server Problems

Case Study #6 Comparing Scenario Results

- 61 -

Performance

LoadRunner Monitors LoadRunner Controller is integrated with real-time monitoring capabilities. Real-time monitoring helps to record all the system and application related information during the entire run of the test with definite sampling interval. This would help to isolate, identify and resolve performance bottlenecks through the analysis of the data collected through the various system counters collected during monitoring. List of Key LoadRunner Monitors Windows Resource Monitor Unix Resource Monitor Web Server Monitors (Apache, IIS, iPlanet) Database Monitors (Oracle, DB2, SQL Server, Sybase) Application Server Monitors (Weblogic, Websphere, Oracle 9i Apps Server) ERP/CRM Server Resource Monitors (Siebel, SAP, Peoplesoft) Middleware Resource Monitors (Tuxedo, IBM MQ Series)

AUTHOR: PRINCE RAJKUMAR J Email : princerajkumar.j@tcs.com CO - AUTHOR: MADAN MOHAN.NARALA Email : madanmohan.n@tcs.com

- 62 -