Thursday, February 16, 2012

Controller Interview Questions




1) Easy to use tool
2) Learning curve for a beginner is very low compared with the other tool
3) Vast variety of application and protocol support
4) Scripting is very easily done by using VuGen
5) The 
load test can be designed exactly similar to realistic loads tests using manual scenarios
6) The load tests can also be designed based on the goals of the customer, by way of goal oriented scenarios
7) The 
service level agreements or objectives can be set and will be evaluated during the load test analysis phase
8) The results can be easily analyzed and comparison graphs and reports can be generates using analysis component
9) The loads can be generated using different remote load generators with more 
number of users by way multiple thread mechanism
10) Support from HP is good.
11) There is lots of online help and forums available for any issues
12) The resources for loadrunner is also easy to get in the industry


The types of load testings supported by loadrunner are:
Load Testing: By using the loadrunner the load test can be simulated for multiple simultaneous users, similar to realistic number of users.
Endurance / Longevity / Soak Testing: By using the loadrunner the load test can be simulated for longer durations
Stress Testing: By using the loadrunner the load test can be simulated with multiple users till the stress point reaches with incremental increase in the number of users.
Spike Testing: By using the loadrunner, during the load test execution spikes can introduced by way of adding thenumber of users.
Capacity Testing: Using loadrunner systems capacity can be tested for the future incremental in business. For example, if the current AUT system configuration supports 1000 users. Due to the expansion in business, if the numberof users are increased to 10000. Does the existing environment supports or any new systems to be procured. The decision can be taken by way of conducting the load tests using load runner.
Scalability Testing: Scalability can be compared using some of the auto generated graphs, like average response times under load.


The scenario types available in loadrunner controller are:
1) Manual scenario
2) Manual scenario by percentage
3) Goal oriented scenario


 Goal Oriented scenario is one type of load test scenario in controller.
Goal Oriented scenario is used for creating the scenario based on the customer expected objectives.
For example: if the customer wants to achieve the 100 hits per second with variable number of users like minimum number of users 50 and maximum number of users 150. Then you may need to select the type of load test as goal oriented.
Normally the goal oriented scenario should be executed for long durations to achieve the customer goals or objectives.
Manual scenario is one of the types of load runner scenarios. This will be used for simulating the real time load tests.
The manual scenario can be built by creating groups and specifying the script, the load generator, and the number of Vusers included in each group
Manual scenario
Goal oriented scenario
Used to simulate the real time loads based on the fixed time and fixed number of virtual users
Used for simulating the load, based on the objectives defined by the customer expected objectives like HTTP hits, transactions per sec and transaction response time etc.
The duration is fixed. Since the time clearly defined in real world scehdules
The duration is always much more than the duration mentioned in goal oriented scenarios. Since the goal will be achieved after the mentioned time
Acceleration and deceleration of the users will happen based on theschedule design
Acceleration and deceleration of the users will happen automatically, based on the goal defined


Goal oriented scenario: 
The goal oriented scenario is selected, only when you want to simulated the customer objectives or goals like HTTP hits per second or transactions per second or transaction response time.
Manual scenario: 
Manual scenario will selected when you want to simulate the number of virtual users according to the real time load behavior of the users.

1)   From controller Select menu option File -> New
2) New Scenario 
Dialog box pops up
3) Select the goal oriented scenario radio button
4) Add the appropriate scripts
5) Click OK button
6) New scenario opens in the controller
7) Click on "Edit scenario goal" button in scenario goal
8) Edit scenario goal pops up
9) Click on New button
10) New Goal profile dialog opens
11) Enter the name and press OK
12) Now, you can set the new profile settings

To define Scenario Goal, we choose different types of goals based on the customer given objectives for the load test.
There are 5 types of goals available. Select the type of goal you want for the scenario.
Pages per Minute (for Web Vusers only). Enter a target number of downloaded pages per minute that you would like your scenario to reach, and select a minimum and maximum number of Vusers for the scenario.
Virtual Users. Enter a target number of virtual users that you would like your scenario to reach.
Hits per Second (for Web Vusers only). Enter a target number of hits per second (HTTP requests per second) that you would like your scenario to reach, and select a minimum and maximum number of Vusers for the scenario.
Transactions per Second. Enter a target number of transactions per second that you would like your scenario to reach, and select a minimum and maximum number of Vusers for the scenario.
Transaction Response Time. Enter a target transaction response time that you would like your scenario to reach, andselect a minimum and maximum number of Vusers for the scenario.

Using the load behavior tab, you can set when the ramp up to achieve the goal.
The ramp up can be set in three ways
Automatic. Instructs the Controller to run the default number of Vusers in a batch. Controller starts with the minimum number of Vusers. And runs for two minutes. If the goal is not achievable, the scenario automatically increases the users to achieve the goal.
Reach target X after. Select the amount of scenario time you want to elapse before the Controller reaches your target. This is the minimum time you have given. The controller takes much larger time than mentioned here.
Step up by (not available for the Transactions per Second and Transaction Response Time goal types). Select the gradation according to which you want the Controller to reach your target (x number of virtual users/hits/pages every x amount of time).

There is a check box Do not change recorded think time in Edit scenario goal. If it is not checked, the controller will minimize the think time, and runs the load test. So, due to reduction in think time the frequency of the hits will increase.
Note: If you select this option, you may need to increase the number of Vusers in your scenario in order to reach your target



Goal oriented scenario scenarios will execute based on the goals defined. The main objective of the goal oriented scenario is to maintain the goal throughout the load test execution.
For example: You are running goal oriented scenario with the goal of 100 hits per second, with minimum number of users as 50 and maximum number of users as 150. If the actual hits per second is coming around 75, when the load test is running with 50 users, then the controller automatically increases the number of users based on the required hits. When the number of hits are above the goal, then the number of users will be decreased accordingly
During the goal oriented scenario profile creation, you have to select the appropriate option for continuation or termination of load test, if the goal is not achievable.
There are two options available to choose for non-achievable goals:
Stop scenario and save results. Instructs the Controller to stop the scenario and save the scenario results, if the target you defined cannot be reached.
Continue scenario without reaching goal. Instructs the Controller to continue running the scenario, even if the target you defined cannot be reached.
If you want to get notified during the goal oriented scenario, if the goal is not reachable. Select the option
Receive notification. Instructs the Controller to send you an error message indicating that the target cannot be reached.
Load generator Load generator is a component of loadrunner. Load generator is used for creation of the virtual users.

Load generators can be added to controller with the below mentioned steps.
1) Select the menu option "Scenario -> Load generators" in controller
2) Load generators dialog box opens
3) Click on Add button
4) Enter the name or ip address of the load generator
5) Select the platform Windows or UNIX
6) Enter the temporary directory
7) Click OK button


The operating systems supported by load generator are:
1) 
Windows
2) UNIX

If you have not mentioned the temporary folder for load generator, the results will be stored in the mentioned folder.
Otherwise, the load generator is going to store the results in the temporary folder in the current user profile as:C:\Documents and Settings\<user name>\Local Settings\Temp\.
To see the actual folder, open the load generator details, and see the temporary folder to get the actual folder name with full path.
To check the load generators
1) Select the load 
generator and click on connect
2) Observe the status of the load generator
3) If the load generator status is ready, that means the load generator can be used for execution of the load test
4) If the load generator status is failed, that means that load generator is not ready for execution

The group is combination of VuGen test script, number of virtual users and the load generator.
Each group can also be associated with its own run time settings.
Yes, the same script can be used part of the multiple groups.
Click on Add group from the controller scenario. When you choose same script from the test script list, every time you add the test script, load runner generates different name for the group by suffixing a number. You can change the name of the group while adding the test script.
In the scenario group section there is a load generator group column.
Associate each of the load generator with each group.
A group can be added to the scenario with the below mentioned steps:
1) Click on Add group button
2) Enter the name of the group
3) Enter the number of Vusers quantity
4) Select the load generator
5) Select the script to be part of the group
6) Press OK
Now your new group has been added to the scenario
Users from a group can be deleted with the below mentioned steps:
1) Select the group from the controller scenario
2) Click on the vuser group button
3) Select the number of users needs to be deleted
4) Press the Delete key from your keyboard
A single user can be executed on a specific load generators with the below mentioned steps:
1) Select the group from the controller scenario
2) Click on the vuser group button
3) Select the Vuser, the vuser could have been pointed to the script and load generator
4) Click on run button. The selected vusers will be executing
Enable Rendezvous/Disable Rendezvous : Enables or disables the selected rendezvous points from participating in the scenario.
The rendezvous option will be enabled or disabled with the below mentioned steps:
1) Open the controller scenario
2) Select the menu option scenario -> Rendezvous...
3) Rendezvous Information dialog box opens
4) Select the name of Rendezvous point
5) Click on Enable (or Disable) Rendezvous button
Policy. 
Opens the Policy dialog box, enabling you to set how many Vusers are released from a rendezvous at a time, as well as the amount of time the Controller waits before releasing Vusers from a rendezvous.
The options are:
1) Release when 100% of all vusers arrive at the rendezvous
2) Release when 100% of all running arrive vusers at the rendezvous
3) Release when number of vusers arrive at the rendezvous


Timeout. Enter the timeout value (in seconds). After each Vuser arrives at the rendezvous point, LoadRunner waits up to the number of timeout seconds specified for the next Vuser to arrive. If the next Vuser does not arrive within the timeout period, the Controller releases all the Vusers from the rendezvous. Each time a new Vuser arrives, the timer is reset to zero. The default timeout is thirty.
Timeout is set based on the execution time of the virtual users.
Enable Rendezvous/Disable Rendezvous : Enables or disables the selected rendezvous points from participating in the scenario.
The rendezvous option will be enabled or disabled with the below mentioned steps:
1) Open the controller scenario
2) Select the menu option scenario -> Rendezvous...
3) Rendezvous Information dialog box opens
4) Select the name of Rendezvous point
5) Click on Enable (or Disable) Rendezvous button
Scenario start time can be set with the below mentioned steps
1) Open the manual scenario
2) Click on Start time button on Scenario Schedule
3) Enter the start scenario time
a) without a delay
b) with a delay of
c) at a specific time

There are two types of schedules available in scenario. Those are
1) Schedule by scenario
schedule the scenario to start running at a specified time. You can limit the execution duration of the scenario or of a Vuser group within the scenario.
You can also stipulate how many Vusers to start and stop running within a certain time frame. You can specify whether LoadRunner should start or stop running all Vusers in a scenario simultaneously, or only a certain number of Vusers within a specified amount of time.

2) Schedule by group
For each enabled Vuser group in a scenario, you can design a separate execution schedule. You can specify when to start running the Vuser group, how many Vusers to start and stop running within given time intervals, and how long the Vuser group should continue running.
For each of the above, the run modes are:
1) Run by Real word schedule
The scenario runs according to a user-defined group of actions that simulate a real-world schedule of events. Vuser groups run according to the iterations defined in their run-time settings, but you can define how many Vusers to run at a time, how long Vusers should continue to run, and how many Vusers to stop running at a time.
2) Run by Basic schedule (or until complete in older versions) 
All enabled Vuser groups run together on one schedule, each according to its own run-time settings. You can schedule how many Vusers to start running at a time, how long to run the Vusers, and how many Vusers to stop running at a time.
The actions available in loadrunner controller scenario are:
1) Start Group The Start Group action defines when to start running a Vuser group. This action is available for group schedules only.
Note: By default, the Start Group action appears as the first action in the Actions grid when you select Schedule by: Group. It is always followed by the Initialize action. It cannot be deleted.
2) Initialize
The Initialize action instructs LoadRunner to prepare the Vusers so that they are in the Ready state and can run.
Note: By default, the Initialize action appears in the Actions grid for all schedule types. It cannot be deleted.
3) Start Vusers
The Start Vusers action instructs LoadRunner to start running Vusers.
4) Duration
The Duration action instructs LoadRunner to continue running the scenario in the current state, for the specified amount of time.
5) Stop Vusers
The Stop Vusers action instructs LoadRunner to stop the running Vusers.
The options available in loadrunner controller scenario are:
Initialize all Vusers simultaneously 
LoadRunner initializes all the Vusers in the scenario or selected Vuser group together, before running them.
Initialize XX Vusers every <00:00:00> (HH:MM:SS) 
LoadRunner initializes the specified number of Vusers gradually before running them, according to the specified time interval (in hours, minutes, and seconds).
Initialize each Vuser just before it runs 
(Default) LoadRunner initializes each Vuser in the scenario or selected Vuser group just before it starts running.
Note: The above option is not available for Group schedules when the Wait for all groups to initialize option is selected. See Initializing All Vuser Groups Before a Run.
Start XX Vusers: Simultaneously (Default)
LoadRunner runs the specified number of Vusers simultaneously
Start XX Vusers: YY Vusers every <00:00:00> (HH:MM:SS) LoadRunner runs the specified number of Vusers (XX) gradually. That is, LoadRunner runs YY Vusers, and waits the specified time (in hours, minutes, and seconds) before running another YY Vusers.
Run until completion 
The scenario runs until all the Vusers have finished running.
Note: In a Real-world schedule, this option is available after the first time the Vusers start running only.
Run for XX days and <00:00:00> (HH:MM:SS) 
The scenario runs in its current state for the specified amount of time (in days, hours, minutes, and seconds) before continuing with the next action.
The default Duration period is 5 minutes.
Run indefinitely 
(Basic schedule only) The scenario runs indefinitely.
Stop vusers action of global schedule will be having the following options:
Stop XX Vusers: Simultaneously 
(Default) LoadRunner stops the specified number (All or XX) of running Vusers at once.
Stop XX Vuser: YY Vusers every <00:00:00> (HH:MM:SS)
LoadRunner stops the specified number of Vusers (All or XX) gradually. That is, LoadRunner stops YY Vusers, and waits the specified time (in hours, minutes, and seconds) before stopping another YY Vusers.
The action types available in loadrunner controller scenario are:
1) Start Vusers
The Start Vusers action instructs LoadRunner to start running Vusers.
2) Duration
The Duration action instructs LoadRunner to continue running the scenario in the current state, for the specified amount of time.
3) Stop Vusers
The Stop Vusers action instructs LoadRunner to stop the running Vusers.
1) Start Group The Start Group action defines when to start running a Vuser group. This action is available for group schedules only.
Note: By default, the Start Group action appears as the first action in the Actions grid when you select Schedule by: Group. It is always followed by the Initialize action. It cannot be deleted.
2) Initialize
The Initialize action instructs LoadRunner to prepare the Vusers so that they are in the Ready state and can run.
Note: By default, the Initialize action appears in the Actions grid for all schedule types. It cannot be deleted.
3) Start Vusers
The Start Vusers action instructs LoadRunner to start running Vusers.
4) Duration
The Duration action instructs LoadRunner to continue running the scenario in the current state, for the specified amount of time.
5) Stop Vusers
The Stop Vusers action instructs LoadRunner to stop the running Vusers.
the options available in loadrunner controller scenario Start group action are:
In the Start/Stop Vusers box, enter the number of Vusers to start/stop running, and select whether to:
start/stop running all the Vusers simultaneously
start/stop running the Vusers gradually
In this case, enter the number of Vusers to start/stop at a time, and at what time interval
The results folder to write the results in a specific folder will be done with the below mentioned steps:
1) Select 
the menu options Results -> Results Settings...
2) Set Results Settings Directory Dialog box opens
3) Enter the "Results Name"
4) Enter the Directory path
The user status will change as mentioned in the order of sequence:
1) Down The Vuser is down.
2) Pending The Vuser is ready to be initialized and is waiting for an
available load generator, or is transferring files to the load generator. The Vuser will run when the conditions set in its scheduling attributes are met.
3) Initializing The Vuser is being initialized on the remote machine.
4) Ready The Vuser already performed the init section of the script and is ready to run.
5) Running The Vuser is running. The Vuser script is being executed on a load generator.
6) Rendezvous The Vuser has arrived at the rendezvous and is waiting to be released by LoadRunner.
6) Done.Passed The Vuser has finished running. The script passed.
7) Done.Failed The Vuser has finished running. The script failed.
8) Error A problem occurred with the Vuser. Check the Status field on the Vuser dialog box or the output window for a complete explanation of the error.
9) Gradual Exiting The Vuser is completing the iteration or action it is running (as defined in Tools > Options > Run-Time Settings) before exiting.
10) Exiting The Vuser has finished running or has been stopped, and is now exiting.
11) Stopped The Vuser stopped when the Stop command was invoked.

Service level agreements (SLAs) enable you to define goals for your load test scenario.
During a scenario run, the Controller measures the performance and collects data.
Analysis compares this data against thresholds defined in the SLAs.

There are two types of Service Level Agreements available
SLA status determined at time intervals over a timeline. Analysis displays SLA statuses at set time intervals—for example, every 10 seconds—over a timeline within the run.
1) SLAs for Average Transaction Response Time
2)SLAs for Errors Per Second.
SLA status determined over the whole run. Analysis displays a single SLA status for the whole scenario run.
The analysis displays a single SLA status for the whole scenario run:
1) Total Hits per run
2) Average Hits (hits/second) per run
3) Total Throughput (bytes) per run
4) Average Throughput (bytes/second) per run

The types of load criteria’s available in goal definition are:
1) None
2) Running vusers
3) Hits per second
4) Throughput
5) Transactions per second
6) Transactions per second pass

Thresholds are nothing but the maximum wait points.
Set maximum thresholds for each transaction that you are evaluating.
If you defined load criteria in the previous step, you set thresholds for each transaction per the defined load value ranges.
If you did not define load criteria, you set a single threshold for each transaction.
Enter the relevant thresholds (per load criteria, if defined) in the table displayed at the top the page.
You can edit an existing service level agreement
1) Select the Service level agreement in the existing Service level agreement area
2) Click on edit button
3) Service level agreement goal 
definition window will pop up
4) Edit the goal definition as needed

No, the type of service level agreement cannot be changed.
Once we select the type of service level agreement, the same type will be used in all the cases.
If you want to change the type. The existing service level agreement needs to be deleted. And the new service level agreement needs to be created.
LoadRunner enables you to view data generated during scenario execution using the online monitors. You specify the machines that the Controller will monitor during a scenario execution, and view the data collected by the monitors, using the LoadRunner online graphs.
A primary factor in a transaction's response time is its resource usage. By monitoring resources during a scenario run, you can determine why a bottleneck occurred on a particular machine. LoadRunner's server resource monitors let you keep track of resources used during a scenario. LoadRunner displays the selected resource monitors in real time during test execution. You can select the server resource measurements to monitor both before and during the scenario.
The online monitors are divided into the following categories:
Run-Time Monitors. Display the number and status of Vusers participating in the scenario, as well as the number and types of errors that the Vusers generate.
Transaction Monitors. Display the transaction rate and response time during scenario execution.
Web Resource Monitors. Provide information about the number of Web connections, throughput volume, HTTP responses, server retries, and pages downloaded to the Web servers during the scenario.
System Resource Monitors. Measure the Windows, UNIX, Tuxedo, SNMP, and SiteScope resources used during a scenario.
Network Delay Monitor. Displays information about the network delays on your system.
Firewall Monitor. Measures statistics of the firewall servers during the scenario.
Web Server Resource Monitors. Measure statistics of the Microsoft IIS, iPlanet (SNMP), and iPlanet/Netscape Web servers during the scenario.
Web Application Server Resource Monitors. Measure statistics of the Ariba, iPlanet (NAS), Microsoft ASP, WebLogic (SNMP), and WebSphere application servers during the scenario.
Database Server Resource Monitors. Measure statistics of the SQL server, Oracle, and DB2 databases during the scenario.
Streaming Media Monitors. Measure statistics of the RealPlayer and Media Player client during the scenario.
ERP/CRM Server Resource Monitors. Measure statistics of the SAP Portal, SAP CCMS, SAPGUI, Siebel Server Manager, Siebel Web Server, and PeopleSoft (Tuxedo) servers during the scenario.
Java Performance Monitor. Measures statistics of Java 2 Platform, Enterprise Edition (J2EE) objects, and Java-based applications, using J2EE machines.
J2EE & .NET Diagnostics Monitors. Provide information to trace, time, and troubleshoot individual transactions through J2EE & .NET Web, application, and database servers.
Application Component Monitor. Measures statistics of the Microsoft COM+ server during a scenario run.
Application Deployment Solutions Monitor. Measures statistics of the Citrix MetaFrame XP and 1.8 servers during a scenario run.
Middleware Performance Monitors. Measure statistics of the Tuxedo and IBM WebSphere MQ servers during a scenario run.
Infrastructure Resources Monitor. Measures statistics of the network client data points during a scenario run.

The monitors used for validating client side measures of the load test are:
Run-Time Monitors. Display the number and status of Vusers participating in the scenario, as well as the number and types of errors that the Vusers generate.
Transaction Monitors. Display the transaction rate and response time during scenario execution.
Web Resource Monitors. Provide information about the number of Web connections, throughput volume, HTTP responses, server retries, and pages downloaded to the Web servers during the scenario.
The monitors used during the load test for evaluating the servers performance are:
System Resource Monitors. Measure the Windows, UNIX, Tuxedo, SNMP, and SiteScope resources used during a scenario.
Network Delay Monitor. Displays information about the network delays on your system.
Firewall Monitor. Measures statistics of the firewall servers during the scenario.
Web Server Resource Monitors. Measure statistics of the Microsoft IIS, iPlanet (SNMP), and iPlanet/Netscape Web servers during the scenario.
Web Application Server Resource Monitors. Measure statistics of the Ariba, iPlanet (NAS), Microsoft ASP, WebLogic (SNMP), and WebSphere application servers during the scenario.
Database Server Resource Monitors. Measure statistics of the SQL server, Oracle, and DB2 databases during the scenario.
Streaming Media Monitors. Measure statistics of the RealPlayer and Media Player client during the scenario.
ERP/CRM Server Resource Monitors. Measure statistics of the SAP Portal, SAP CCMS, SAPGUI, Siebel Server Manager, Siebel Web Server, and PeopleSoft (Tuxedo) servers during the scenario.
Java Performance Monitor. Measures statistics of Java 2 Platform, Enterprise Edition (J2EE) objects, and Java-based applications, using J2EE machines.
J2EE & .NET Diagnostics Monitors. Provide information to trace, time, and troubleshoot individual transactions through J2EE & .NET Web, application, and database servers.
Application Component Monitor. Measures statistics of the Microsoft COM+ server during a scenario run.
Application Deployment Solutions Monitor. Measures statistics of the Citrix MetaFrame XP and 1.8 servers during a scenario run.
Middleware Performance Monitors. Measure statistics of the Tuxedo and IBM WebSphere MQ servers during a scenario run.
Infrastructure Resources Monitor. Measures statistics of the network client data points during a scenario run.
The types of graphs comes under client side monitoring:
1) Running vusers
2) Transaction Response Time
3) User Defined Data Points
4) Total Transaction / Sec
5) Hits per Second
6) Throughput
7) Error Statistics

The default number of graphs used in loadrunner are: 4
One can also view one, two, four, eight and at the maximum 16 graphs can be viewed.
If one want to view more than sixteen, it is not possible in loadrunner
Follow the below mentioned steps to view the graphs
Select the Menu option View-> View Graphs -> Enter the number of graphs to be viewed
Follow the below mentioned steps to add the monitor graph in load runner controller
1) Open the controller scecnario
2) Select the Run tab (in the bottom) of controller
3) View the graphs more than 8 (View -> View Graphs ->Enter 
number 8)
4) Drag the desired graph and drop into the graph area
5) Right Click on the graph and select Add measurements
6) Dialog pops up based on the counter you have chosen
7) Click on Add button
8) Add machine dialog box pops up
9) Enter the host name
10) Select the appropriate platform
11) Click OK
To add the monitor graph follow the steps mentioned in 54. How do you add a monitor graph in loadrunner controller?
The additional measures for a windows based server can be added with the below mentioned steps:
1) If there are any custom counters needs to be added click on Add button from measurements area (in the bottom)
2) If the server is a remote machine, it will pop up with server authentication dialog box.
3) Enter the credentials and click ok
4) If the server is s windows machine, it will show the windows resources dialog box
5) Select the object type
6) Select the counters for respective object
7) Click on add
8) Repeat the step 5 to 7 till all the counters gets added
9) Finally click close, then all the added counters can be seen from Resources measure on host
10) Click OK, then all the measures starts monitored on the controller
The default counters or measures for windows monitors given by load runner are:
% Disk Time (PhysicalDisk _Total)
Disk Time is the percentage of elapsed time that the selected disk drive is busy servicing read or write requests.
% Processor Time (Processor _Total)
% Processor Time is the percentage of time that the processor is executing a non-Idle thread. This counter was designed as a primary indicator of processor activity. It is calculated by measuring the time that the processor spends executing the thread of the Idle process in each sample interval, and subtracting that value from 100%. (Each processor has an Idle thread which consumes cycles when no other threads are ready to run). It can be viewed as the percentage of the sample interval spent doing useful work. This counter displays the average percentage of busy time observed during the sample interval. It is calculated by monitoring the time the service was inactive, and then subtracting that value from 100%.
Available MBytes (Memory)
Available MBytes is the amount of physical memory available to processes running on the computer, in Megabytes, rather than bytes as reported in Memory\\Available Bytes. It is calculated by adding the amount of space on the Zeroed, Free, and Stand by memory lists. Free memory is ready for use; Zeroed memory are pages of memory filled with zeros to prevent later processes from seeing data used by a previous process; Standby memory is memory removed from a process' working set (its physical memory) on route to disk, but is still available to be recalled. This counter displays the last observed value only; it is not an average.
File Data Operations/sec (System)
File Data Operations per second is the rate that the computer is issuing Read and Write operations to file system devices. It does not include File Control Operations.
Interrupts/sec (Processor _Total)
Interrupts/sec is the average number of hardware interrupts the processor is receiving and servicing in each second. It does not include 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 during interrupts. Most system clocks interrupt 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.
Page Faults/sec (Memory)
Page Faults/sec is a count of the Page Faults in the processor. A page fault occurs when a process refers to a virtual memory page that is not in its Working Set in main memory. A Page Fault will not cause the page to be fetched from disk if that page is on the standby list, and hence already in main memory, or if it is in use by another process with whom the page is shared.
Pages/sec (Memory)
Pages/sec is the number of pages read from the disk or written to the disk to resolve memory references to pages that were not in memory at the time of the reference. This is the sum of Pages Input/sec and Pages Output/sec. This counter includes paging traffic on behalf of the system Cache to access file data for applications. This value also includes the pages to/from non-cached mapped memory files. This is the primary counter to observe if you are concerned about excessive memory pressure (that is, thrashing), and the excessive paging that may result.
Pool Nonpaged Bytes (Memory)
Pool Nonpaged Bytes is the number of bytes in the Nonpaged Pool, a system memory area where space is acquired by operating system components as they accomplish their appointed tasks. Nonpaged Pool pages cannot be paged out to the paging file, but instead remain in main memory as long as they are allocated.
Private Bytes (Process _Total)
Private Bytes is the current number of bytes this process has allocated that cannot be shared with other processes.
Processor Queue Length (System)
Processor Queue Length is the instantaneous length of the processor queue in units of threads. This counter is always 0 unless you are also monitoring a thread counter. All processors use a single queue in which threads wait for processor cycles. This length does not include the threads that are currently executing. A sustained processor queue length greater than two generally indicates processor congestion. This is an instantaneous count, not an average over the time interval.
Threads (Objects)
Threads is the number of threads in the computer at the time of data collection. Notice that 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.
To add the monitor graph follow the steps mentioned in 54. How do you add a monitor graph in loadrunner controller?
The additional measures for a windows based server can be added with the below mentioned steps:
1) If there are any custom counters needs to be added click on Add button from measurements area (in the bottom)
2) If the server is a remote machine, it will pop up with server authentication dialog box.
3) Enter the credentials and click ok
4) If the server is s windows machine, it will show the windows resources dialog box
5) Select the object type
6) Select the counters for respective object
7) Click on add
8) Repeat the step 5 to 7 till all the counters gets added
9) Finally click close, then all the added counters can be seen from Resources measure on host
10) Click OK, then all the measures starts monitored on the controller
Loadrunner diagnostics are used for profiling the application server code and database server for identifying the issues at the code or database level.
For example, if there is any transaction is taking more than expected time. For getting the detailed information on which of the servers are causing the problem for the high response time, we use diagnostics.
Using diagnostics we can easily pin point the problem on the application server, which API is causing the problem.
Similarly we can also pin point the problem on the database which of the SQL/SQLs is/are causing the problem.




Using the multiple run time settings we can set the common settings for multiple groups at a time.
The multiple run time settings mode can be chosen with the below mentioned steps:
1) Open the controller scenario
2) Select the multiple groups on the controller
3) Click on the run time settings
4) The dialog box "Modifying Run-Time Settings for Multiple Scripts" opens

The Modifying Run-Time Settings for Multiple Scripts will be invoked with the link:- 59. How do you enable multiple run time settings mode?
Select a method for modifying run-time settings of multiple scripts:
Shared RTS. Opens one window containing all of the run-time settings in blank mode. In this mode, you set only the options that you would like to modify for all selected scripts. All other run-time settings remain unchanged.
1) In shared RTS, all the fields will be with blank settings
2) Used for setting common settings
Individual RTS. Opens a separate window for each selected script. In this mode, you modify each script's settings individually.
1) Individual RTS, all the fields will be with default or initial settings
2) Used for giving individual run time settings for each script



No comments:

Post a Comment