Load Runner Versions: 8.0, 8.1, 9.0, 9.1, 9.5 and 11 Load Runner version 11.

0 supports windows operating system. Load Runner 9.5 Released in 2009 New Features Protocol Advisors Newly added array functions Load Runner Components: 1. VU Generator: used to generate/develop/enhance the vuser business scripts for all the scenarios which are in scope c language. 2. Controller : used to execute scripts with multiple users 3. Analysis: Validate the test execution results with the expected behavior i.e. (SLA) 4. Load Generator: It generates the amount of vusers to run on the server. 5. Agent Process: It establishes a communication between the load generator and controller Virtual User Generator Controller load generator agent process analysis Virtual user Generator:
This component is used to generate the script for each business process or scenario with the supported protocol.

Protocol Advisor:
This is a new feature of Load Runner 9.5 and it identifies the supported protocols by the application under test or the business process. WebTours URL http://127.0.0.1:1080/WebTours/ username/password : jojo/bean By using a protocol advisor, we identified the below types of protocols that supports for the application business proces. Ajax (click and script) Web (HTTP/HTML) Selecting an appropriate protocol: 1. Protocol advisor has identified two protocols supported by application under test but we have to use only one protocol for performance testing. 2. It would be better to go with Web protocol first and then go for ajax if it does not support web lets 3. The reasons to select web protocol is quite obvious, the licence cost for generating virtual users is of ration 1:10 for web and ajax and also memory constraints, Web protocol consume 2MB where as Ajax protocol consumes 10 MB per virtual user

Select the protocol as web (HTTP/HTML) to generate the script:

Recording Modes:
Load Runner has two types of recording modes

HTML Based Recording:

1. 2. It generates the script for HTML Source of the web page. Generates web vuser functions for each user action on the web page

3.

Functions in html recording are web_link, web_submit_form, web_url, web_submit_data

URL Based Recording: 1. It generates script for non html resources like .jpg, .bmp, .gif and css files.
2. 3. It generates separate web functions for each non html resource on a web page. Functions it supports are Web_url, web_submit_url, web_custom_request

Note: It is recommended to user html based recording over url based recording as it focuses on user actions. Correlation:
Correlation is handle the data generated by server There are two types of correlation process that supports load runner. Automatic Correlation Manual Correlation Automatic Correlation: Handle server generated data with the help of tool functionalities is called automatic correlation 1. Scan script for correlation generate the script for end to end business scenario, run the script and I observed a problem in handling sessions ids generated by the script ie an error with session while logging into application. 2. Select > View > Scan Script for correlation> The differentiate values between the recording and replay will display under correlation results 3. Select the value and click correlate 4. It will automatically insert the correlated function with all the arguments 5. The correlation function web_reg_save_param( "WCSParam_Diff1", "LB=userSession value=", "RB=>", "Ord=3", "IgnoreRedirections=Yes", "Search=Body", "RelFrameId=1.2.1", LAST );)

Second method: creating a correlation rule

1. 2. 3. 4. 5. 6. Enable correlation in recording settings Create new application and create new rule Assign the left boundary and right boundary values and define the ORD number Generate the script with end to end business actions It will automatically insert the correlation function with all the arguments doing the script recording When u reply the script, it should successfully run without any session issues

Manual Correlation:
1. Identify correlated values: record same scenario twice and save each script. Go to Tools>Compare with Script from one of the saved scripts, a dialog will open, now select the other script. A file with differences between the two scripts is displayed ie..Wdiff. From the Wdiff we can figure out the values that could be correlated. The differences are are highlighted in yellow lines.

Identify the required correlated value from the differences, important thing to note while comparison is that only server generated values have to be considered for correlation, not all the differences such as think time, x-y co-ordinates. 2. Capture the server generated value: use correlated function web_reg_save_Param() web_reg_save_param( "ParamName", "LB= ", "RB=>", "Ord=", "IgnoreRedirections=Yes", "Search=Body", "RelFrameId=", LAST );) The sessionid or session value is generated by the server, in order to capture the server generated value, we have to search in the previous client request, ie.. say in the script a function is requesting the server with a session value, this is sent by client to server, so in order to pass the session id dynamically to the current function, we have to go to the previous function in the script. Copy the identified correlated value, Go to view > Tree

Search for the correlated value in the response, identify the left boundary and right boundary of the correlated value. Then identify the ordinal value of the correlated value, ie. Search if there are similar tags existing in the response with same left and right boundary, if exists then list them down in the notepad. Then, the position in which the correlated value is nothing but ord value

Go to script view, insert the correlated function with all the arguments before the previous request. web_reg_save_param("sessionID","LB=<input type=hidden name=userSession value=","RB=>","ORD=3",LAST); When you replay the script the given parameter will capture the data at run time Save it into variable: By default it saves the new value into the given parameter for a specific ord number ii) we need to save a required value into the separate variable whenever ord = all Replace the variable at all the places of original values in the script. Replay the script and verify the log as well as results file

3. 4.

Correlated Functions Arguments:

Correlated function lr_reg_save_parm() can save into a variable or an array based on ord value if the ord value is specific say 1 then the value would be saved into a vaiable. If ord is all ie.. ord=all then, the values would be stored as array Arguments: a. Parameter name: It Saves the data matching the given boundary b. LB: It is the left boundary of the correlated data c. RB: It is the right boundary of the correlated data d. ORD: it is the ordinal value of the correlated data, It defines a position or occurrence of the correlated value between the give left and right boundaries Example: ORD=1, it captures the first position value between the given boundaries. ORD=2 It captures the second position value between the given boundaries. ORD=all It captures all the position values between the given left and right boundaries.

Randomly selecting values from load runner parameter or correlation array parameter
When you user ord = all, correlated parameter captures list of values in an array. So, use the below randomized function to select the random value from the array. It captures a specific index value from the array list lr_parmarr_idx(arrayparameter, index) lr_parmarr_random(arrayparameter) It takes a random value from the available array range lr_paramarr_len (arrayparameter) Returns the length of the array passed as parameter Note: all the above array functions are available from loadrunner 9.5 1. To calculate the length of the given array use the below syntax arrPrmcnt = atoi(lr_eval_string(arrayparm_count)); cityCount = atoi(lr_eval_string("{city_count}")); To select a random value from the available range use the below syntax cityCount = atoi(lr_eval_string("{city_count}")); city: rndNum1 = rand()%cityCount+1; rndNum2 = rand()%cityCount+1; sprintf(fromCityParm,"{city_%d}",rndNum1); sprintf(toCityParm,"{city_%d}",rndNum2); sprintf(toCity,"%s",lr_eval_string(toCityParm));

2.

Parameterization:
Passing different set of inputs instead of original values in the script

Sequential each iteration: Parameterize a value in the script, ie.. select a value in the script, right click on the value and select replace with parameter, a dialog opens with multiple options, enter the parameter name and select file as parameter type.
GoTo > vusers>Parameters list, a dialog with all the parameters would be listed. Select the parameter created above, and click edit with note pad option and give multiple values and then save it. All the multiple values given in the note pad are reflected in the parameter list dialog.

Then select next row as sequential and update value on as each iteration and then click Simulate Parameter button. Parameter simulation daialog is opened.

Select number of virtual users and Number of iternations to run and click on simulate button.

If above screen shot is observed, for each iteration the vusers are same, this is the drawback of sequential iterations iefor each iteration the vuser would be sequentially assigned but the vusers are same in each iteration. Sequential Once Then select next row as sequential and update value on as Once and then click Simulate Parameter button.A single sequential parameter value will be assigned for all the iterations done by the vuser Note: In all the sequential combinations the data which is passed for the first vuser, the same date would be assigned to remaining vusers.

Random each iteration: Then select next row as Random and update value on as Each Iteration and then click Simulate Parameter button. The new random parameter value will be updated for each iteration of the script execution ie.. the parameter value passed for a virtual user is different in each iteration.

Random Once: Then select next row as Random and update value on as Once and then click Simulate Parameter button. A single random parameter value would be assigned for all the iterations done by the vuser

Unique each iteration Select next row as Unique and update value on as Each Iteration and then click Simulate Parameter button. Here, additional options are enabled in the parameter list dialog. Allocate Vuser values in the controller would be enabled. This is where we allocate the block size, when we say we want unique value for a vuser that means a value given for a vuser should be unique across iterations and should not be used by the other vusers. So if we mention the range for each vuser ie nothing but block size, say if we select Allocate value for each vuser, as 10 first vuser would be assigned 1-10 valules from the file, the next vuser would be assigned values from 11-20 in the file and so on.. If we select Autmatically allocate block size, load runner itself would allocate the block size based on number of iterations. The unique parameter value would be assigned for each iteration of the script execution

Block Size: Allocate the block size for each user based on the iterations File Size: Allocate the parameter values in a file based on number of users and iterations for example if there are 5 vusers in 10 iterations, the file size should be 5*10 i.e. 50 Unique Once A single parameter value would be assigned for all the iterations done by the vuser

Each Occurrence: When same Parameter is used multiple times in an action, each occurrence would send different data for every occurrence.

It would update a new parameter value for each occurrence of the parameter file in the script.

Multi column Datafiles: It supports the parameter file types as .dat, .txt, .csv

Transaction Points:
Insert transaction points to measure the response time of user actions.

Start Transaction:
lr_start_transaction(*char parmName): ApplicationName_ScenarioName_TransactionNum_Action

End Transaction: Lr_end_transaction(transactionname,status): LR_AUTO: Automatically returns the status of end transaction, either pass or fail or stop. LR_PASS: Returns the status as PASS LR_FAIL: Returns the status as FAIL

Check Points:
Two types of check points are available in load runner Text Check Point Validates the given text on a web page using two functions Web_reg_find(textToFind) : One type of check function to validate, this function we user savecount argument to capture the occurrence of the given text on a web page. Web_find(): It is also one type of text check functions to validate the given text on a web page. Syntax: Web_find(stepname,what=textToVerifty,LAST) web_find No option is available to record the text by default during script recording This function is written after the action functions or after requesting server We need to enable, Image and text check in Runtime Settings > Internet Protocol> Preferences > Enable Image and text check

Web_reg_find It records the title of the page by default by havig advance option in record setting This function is written before the action functions or befor requesting server No need to enable any option to verify during script run or play back

Image Check Point

CONTROLLER:
In this component we will design and execute the multi user performance business secenarios There are two types of scenarios can be designed in load controller scenario. 1) 2) Manual Scenario 2) Goal Oriented Scenario

Manual Scenario:
Create the controller scenario based on the number of virtual users Goal Oriented Scenario: Create the controller scenario based on the below specified goal Goal Types:

1. 2. 3. 4. 5.

Virtual Users Hits per Second Transactions per Second Transaction Response Time Pages per Minute

Execution Process or Summary:

1. 2. 3. Upload all the scripts into the controller which are in scope. Define the vuser load for each script(user mix) Assign the load generator to generate vusers load(How many users should be generated on a load generator?) How do you define how many load generators to be used, and how many users should be used on the generator? Load generators gernerates the amount of vusers to run the script to simulate real word behavior. Based on system configuration of load generator machine generates the load from each load generator. Configuration: for web protocol the recommended users are 1 for 2MB of RAM and for 2GB 500 members. 50% of the memory is used for virtual users and 50% for services to run. Load generator can be configured either in windows or in Unix We can configure load generator from other machines in a controller. Some times its fail to connect to the destination PCs load runner the possible reasons could be either the machine with the given ip address is not started or the agent process software is either not installed or not running on the destination machine. Assigning the multiple load generators into a single script: a. We will add the same script and assign each load generator b. We will assign the multiple load generators into a single line of script using a coma separator Select the script, click on

4.

Load runner VTS(Virtal Table Server): we want to run single script on three different generators, we place the user data on vts server. When first vuser of the first load generator he picks the usernames from the vts server but when the second vuser comes, the first user in vts table gets deleted and second vuser would replace it and the vuser takes the first row. Define the standard runtime settings for each script a) Run Logic: To Define the number of iterations for Actions not and it will not be applicable for Init and End method of the script.

Block Iterations: Number iterations set above ie 20 is applicable for all the action, the above script has only one action even if there are multiple actions in the script the same number of iterations are applicable to the actions. Running different actions in the script with different iterations, to do that first delete all the actions from the run time settings, I mean only from run time settings, not from the script. Then insert blocks equal to the number of actions in the script using Insert Block button, now right click on the block and insert one action each.

After inserting actions to the blocks, right click the action and select Properties option, then the in the dialog box displayed give the block iterations.

Pacing: It is the user waiting time between the iteration executions.

Log: It captures the behavior of script executon into a log file, Note: The recommended log option is send messages only when an error orrurs.

Think Time: Its a user waiting time between the transaction executions.

Miscellaneous: 1. Error Handling a. Continue on error b. Fail open transactions on lr_error_message c. Generate Snapshot on error

It is recommended to select the option Generate Snapshot on error 2. Multithreading a. Run Vuser as a process In process oriented communication; each vuser will be generated using a separate driver program. It consumes more system resources, for multiple .exes b. Run Vuser as a thread In thread communication, a single driver program is created for all vusers in the system. It consumes low system resources as single driver program is created from all VUsers. Note: Its always recommended to select run user as a thread option.

Speed Simulation: In this we can select the bandwidth to user in the executions.

Browser Emulation:

In this we can define all the browser level enhancements 1. Simulate Browser Cache a. Cache URLs requiring cintent(HTMLs) b. Check for newer versions of stored pages every visit on the page. Download non-HTML resources Simulate a new user on each iteration a. Clear cache on each iteration

2. 3.

Proxy: A proxy is a middleware server to validate the request and responses from one network to another network

Preferences:

Advanced options has the following important timeouts

Download filters: 1. User the filter to block unnecessary URLs in the execution

Content Check: It is used to verify the given text on all the user accessing web pages 5. Defien RampUp time: RampUp- It initializes the vusers and server with the given interval time. We can set rampup from the Simultaneously: It initializes all the vusers on the server at the same time Slow RampUp: It initializes the given amount of users on server with the specified interval time We can give the ramp up by clicking on start vusers in the global schedule.Z Note: Always the recommended option is slow rampup Define the steady state period to run all vusers on server Run until completion: it runs vusers on server until completion of the iterations. Note: We need to define the fixed number of iterations to design the scenario for run until completion. Run for duration: It runs all the vusers on server with the given time duration. Note: In this case its not necessary to specify iterations because it will automatically repeat the iteration for given time duration. 7. RampDown Define ramp down(stop vusers) It downs the vusers from server using the below two options. 1. Simultaneous ramp down, slow ramp down

6.

10. Configure the project SLA (Service Level Agreement) 1. Click New in Service Level Agreement Then proceed with selecting multiple options based on the need. 11. Save the results Click on Results settings Save the results with the following format ApplicationName_Load_PerfTestType_Date ArabianBank_100Users_LoadTest_12072011 Ip Spoofing: It assigns one ip address to each virtual user running in the execution. a. b. Generate the required number of ip addresses in corresponding load generator Enable ip spoofer in load controller scenario ie.. Scenario > Enable Ip Spoofer in load controller scenario

Server Side Metrics Configuration:

System level monitors and server level monitoring: Windows System Monitor: 1. 2. 3. Select Windows Resources option under Available graphs or drag the option and drop it on the graph Right click on the Windows Resources option, select Add Measurements option Addd Server machine details in Window Resources dialog, i.e..ipaddress and login details of the system in which the server is set up. Counters % idle time % privileged time Description % Idle Time is the percentage of time the processor is idle during the sample interval % Privileged Time is the percentage of elapsed time that the process threads spent executing code in privileged mode. When a Windows system service in called, the service will often run in privileged mode to gain access to system-private data. Such data is protected from access by threads executing in user mode. Calls to the system can be explicit or implicit, such as page faults or interrupts. Unlike some early operating systems, Windows uses process boundaries for subsystem protection in addition to the traditional protection of user and privileged modes. Some work done by Windows on behalf of the application might appear in

Object Processor

% processor time

% user time

Interrupts/sec

Memory

Available Mbytes

Committed Bytes

% Committed Bytes in use

Page Faults/sec

Page reads/sec

Page writes/sec

Page Input/sec

other subsystem processes in addition to the privileged time in the process. % Processor Time is the percentage of elapsed time that the processor spends to execute a non-Idle thread. It is calculated by measuring the duration of the idle thread is active in the sample interval, and subtracting that time from interval duration. (Each processor has an idle thread that consumes cycles when no other threads are ready to run). This counter is the primary indicator of processor activity, and displays the average percentage of busy time observed during the sample interval. It is calculated by monitoring the time that the service is inactive, and subtracting that value from 100%. % User Time is the percentage of elapsed time the processor spends in the user mode. User mode is a restricted processing mode designed for applications, environment subsystems, and integral subsystems. The alternative, privileged mode, is designed for operating system components and allows direct access to hardware and all memory. The operating system switches application threads to privileged mode to access operating system services. This counter displays the average busy time as a percentage of the sample time. Interrupts/sec is the average rate, in incidents per second, at which the processor received and serviced hardware interrupts. It does not include deferred procedure calls (DPCs), which are counted separately. This value is an indirect indicator of the activity of devices that generate interrupts, such as the system clock, the mouse, disk drivers, data communication lines, network interface cards, and other peripheral devices. These devices normally interrupt the processor when they have completed a task or require attention. Normal thread execution is suspended. The system clock typically interrupts the processor every 10 milliseconds, creating a background of interrupt activity. This counter displays the difference between the values observed in the last two samples, divided by the duration of the sample interval. Available MBytes is the amount of physical memory, in Megabytes, immediately available for allocation to a process or for system use. It is equal to the sum of memory assigned to the standby (cached), free and zero page lists. For a full explanation of the memory manager, refer to MSDN and/or the System Performance and Troubleshooting Guide chapter in the Windows Server 2003 Resource Kit. Committed Bytes is the amount of committed virtual memory, in bytes. Committed memory is the physical memory which has space reserved on the disk paging file(s). There can be one or more paging files on each physical drive. This counter displays the last observed value only; it is not an average. % Committed Bytes In Use is the ratio of Memory\\Committed Bytes to the Memory\\Commit Limit. Committed memory is the physical memory in use for which space has been reserved in the paging file should it need to be written to disk. The commit limit is determined by the size of the paging file. If the paging file is enlarged, the commit limit increases, and the ratio is reduced). This counter displays the current percentage value only; it is not an average. Page Faults/sec is the average number of pages faulted per second. It is measured in number of pages faulted per second because only one page is faulted in each fault operation, hence this is also equal to the number of page fault operations. This counter includes both hard faults (those that require disk access) and soft faults (where the faulted page is found elsewhere in physical memory.) Most processors can handle large numbers of soft faults without significant consequence. However, hard faults, which require disk access, can cause significant delays. Page Reads/sec is the rate at which the disk was read to resolve hard page faults. It shows the number of reads operations, without regard to the number of pages retrieved in each operation. Hard page faults occur when a process references a page in virtual memory that is not in working set or elsewhere in physical memory, and must be retrieved from disk. This counter is a primary indicator of the kinds of faults that cause system-wide delays. It includes read operations to satisfy faults in the file system cache (usually requested by applications) and in non-cached mapped memory files. Compare the value of Memory\\Pages Reads/sec to the value of Memory\\Pages Input/sec to determine the average number of pages read during each operation. Page Writes/sec is the rate at which pages are written to disk to free up space in physical memory. Pages are written to disk only if they are changed while in physical memory, so they are likely to hold data, not code. This counter shows write operations, without regard to the number of pages written in each operation. This counter displays the difference between the values observed in the last two samples, divided by the duration of the sample interval. Pages Input/sec is the rate at which pages are read from disk to resolve hard page faults. Hard page faults occur when a process refers to a page in virtual memory that is not in its working set or elsewhere in physical memory, and must be retrieved from disk. When a page

Page Output/sec

Pages/sec

Pool Nonpaged Allocs

Pool Nonpaged Bytes

Pool Paged allocs

Pool paged Bytes

Physical disk

% disk time % idle time Avg. disk read queue length Avg. disk write queue length Current disk queue length

Process

% processor time

Private bytes Virtual bytes

is faulted, the system tries to read multiple contiguous pages into memory to maximize the benefit of the read operation. Compare the value of Memory\\Pages Input/sec to the value of Memory\\Page Reads/sec to determine the average number of pages read into memory during each read operation. Pages Output/sec is the rate at which pages are written to disk to free up space in physical memory. Pages are written back to disk only if they are changed in physical memory, so they are likely to hold data, not code. A high rate of pages output might indicate a memory shortage. Windows writes more pages back to disk to free up space when physical memory is in short supply. This counter shows the number of pages, and can be compared to other counts of pages, without conversion. Pages/sec is the rate at which pages are read from or written to disk to resolve hard page faults. This counter is a primary indicator of the kinds of faults that cause system-wide delays. It is the sum of Memory\\Pages Input/sec and Memory\\Pages Output/sec. It is counted in numbers of pages, so it can be compared to other counts of pages, such as Memory\\Page Faults/sec, without conversion. It includes pages retrieved to satisfy faults in the file system cache (usually requested by applications) non-cached mapped memory files. Pool Nonpaged Allocs is the number of calls to allocate space in the nonpaged pool. The nonpaged pool is an area of system memory area for objects that cannot be written to disk, and must remain in physical memory as long as they are allocated. It is measured in numbers of calls to allocate space, regardless of the amount of space allocated in each call. This counter displays the last observed value only; it is not an average. Pool Nonpaged Bytes is the size, in bytes, of the nonpaged pool, an area of system memory (physical memory used by the operating system) for objects that cannot be written to disk, but must remain in physical memory as long as they are allocated. Memory\\Pool Nonpaged Bytes is calculated differently than Process\\Pool Nonpaged Bytes, so it might not equal Process\\Pool Nonpaged Bytes\\_Total. This counter displays the last observed value only; it is not an average. Pool Paged Allocs is the number of calls to allocate space in the paged pool. The paged pool is an area of system memory (physical memory used by the operating system) for objects that can be written to disk when they are not being used. It is measured in numbers of calls to allocate space, regardless of the amount of space allocated in each call. This counter displays the last observed value only; it is not an average. Pool Paged Bytes is the size, in bytes, of the paged pool, an area of system memory (physical memory used by the operating system) for objects that can be written to disk when they are not being used. Memory\\Pool Paged Bytes is calculated differently than Process\\Pool Paged Bytes, so it might not equal Process\\Pool Paged Bytes\\_Total. This counter displays the last observed value only; it is not an average. % Disk Time is the percentage of elapsed time that the selected disk drive was busy servicing read or write requests. % Idle Time reports the percentage of time during the sample interval that the disk was idle. Avg. Disk Read Queue Length is the average number of read requests that were queued for the selected disk during the sample interval. Avg. Disk Write Queue Length is the average number of write requests that were queued for the selected disk during the sample interval. Current Disk Queue Length is the number of requests outstanding on the disk at the time the performance data is collected. It also includes requests in service at the time of the collection. This is a instantaneous snapshot, not an average over the time interval. Multispindle disk devices can have multiple requests that are active at one time, but other concurrent requests are awaiting service. This counter might reflect a transitory high or low queue length, but if there is a sustained load on the disk drive, it is likely that this will be consistently high. Requests experience delays proportional to the length of this queue minus the number of spindles on the disks. For good performance, this difference should average less than two. % Processor Time is the percentage of elapsed time that all of process threads used the processor to execution instructions. An instruction is the basic unit of execution in a computer, a thread is the object that executes instructions, and a process is the object created when a program is run. Code executed to handle some hardware interrupts and trap conditions are included in this count. Private Bytes is the current size, in bytes, of memory that this process has allocated that cannot be shared with other processes. Virtual Bytes is the current size, in bytes, of the virtual address space the process is using. Use of virtual address space does not necessarily imply corresponding use of either disk or main memory pages. Virtual space is finite, and the process can limit its ability to load libraries.

Working set

System

Processor queue length

Processes

Threads

TCPv4

Connection failures Connections active Connections established

Working Set is the current size, in bytes, of the Working Set of this process. The Working Set is the set of memory pages touched recently by the threads in the process. If free memory in the computer is above a threshold, pages are left in the Working Set of a process even if they are not in use. When free memory falls below a threshold, pages are trimmed from Working Sets. If they are needed they will then be soft-faulted back into the Working Set before leaving main memory. Processor Queue Length is the number of threads in the processor queue. Unlike the disk counters, this counter counters, this counter shows ready threads only, not threads that are running. There is a single queue for processor time even on computers with multiple processors. Therefore, if a computer has multiple processors, you need to divide this value by the number of processors servicing the workload. A sustained processor queue of less than 10 threads per processor is normally acceptable, dependent of the workload. Processes is the number of processes in the computer at the time of data collection. This is an instantaneous count, not an average over the time interval. Each process represents the running of a program. Threads is the number of threads in the computer at the time of data collection. This is an instantaneous count, not an average over the time interval. A thread is the basic executable entity that can execute instructions in a processor. Connection Failures is the number of times TCP connections have made a direct transition to the CLOSED state from the SYN-SENT state or the SYN-RCVD state, plus the number of times TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD state. Connections Active is the number of times TCP connections have made a direct transition to the SYN-SENT state from the CLOSED state. Connections Established is the number of TCP connections for which the current state is either ESTABLISHED or CLOSE-WAIT.

Step10. Configure the project SLAs

Step11. Save the results

IP spoofing

It assigns one IP address for each user running in the execution. 1. Generate the required number of IP addresses in corresponding load generator 2. Enable IP Spoofer in load controller scenario Server side metric configuration System/OS/Hardware level metrics Windows system:

Object Processor

Memory

Counters % idle time % privileged time % processor time % user time Interrupts/sec Available Mbytes Committed Bytes % Committed Bytes in use

Instances All instances

No instances

Physical disk

Process

System

TCPv4

Page Faults/sec Page reads/sec Page writes/sec Page Input/sec Page Output/sec Pages/sec Pool Nonpaged Allocs Pool Nonpaged Bytes Pool Paged allocs Pool paged Bytes % disk time % idle time Avg. disk read queue length Avg. disk write queue length Current disk queue length % processor time Private bytes Virtual bytes Working set Processor queue length Processes Threads Connection failures Connections active Connections established

All instances

All instances

No instances

No instances

System level monitoring using Perfmon

UNIX OS Level Monitory 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. CPU Utilization System Mode CPU Utilization User mode CPU utilization Interrupt rate Page in Rate Page out rate Memory Paging rate Swap in rate Swap out rate Average Load Collision Rate Context switch rate Disk Traffic Incoming Packets error rate Incoming packets rate Outgoing Packets error rate Outgoing packets rate
CPU

Counter CPU Utilization System Mode CPU Utilization User mode CPU utilization User mode CPU utilization Page in Rate Page out Rate Paging Rate Swap-in-rate Swap-out-rate Average Load Collision Rate Context Switch Rate Disk Traffic Incoming Packets error rate Incoming Packets rate Outgoing Packets error rate Outgoing Packets rate

Description Percent of time that the CPU is utilized. Percent of time that the CPU is utilized in system mode. Percent of time that the CPU is utilized in user mode.. Number of device interrupts per second. Number of pages read to physical memory, per second. Number of pages written to pagefile(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. 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. Rate of disk transfers. Errors per second while receiving Ethernet packets. Number of device interrupts per second. Errors per second while sending Ethernet packets. Outgoing Ethernet packets per second.

Note: To collect the UNIX resources through a controller, rstat daemon process should run in Unix box. Note: UNIX does not have a built in utility to monitor the counters, we have to run different scripts in Unix to monitor the performance counters. Unix Performance Monitoring using shell files: 1. 2. 3. 4. Connect to the UNIX box using a putty Go to the directory where the monitory scripts are located Run all the .sh files before starting of the execution It collects the separate log files for each individual .sh file

Note: To Copy the data from Unix machine to Windows machine and vice versa use WinScp utility.