Data Execution Prevention (DEP) in Windows 7 and above

Problem:
Sometimes, VuGen will not record any events while recording the AUT. If you raise a HP ticket for this problem, HP team will ask you to check your DEP settings is disabled.
Now we see how to disable the DEP settings in Windows 7 and above machines.

Steps:
1. Login to Windows with a user account that has administrative privileges.
2. From a DOS command line run the command "> bcdedit.exe"
Confirm the default value for the "nx" parameter. If it is OptIn, then DEP is enabled.

3. Disable DEP by setting the "nx" parameter to "AlwaysOff" using the command "> bcdedit.exe /set nx AlwaysOff"

4. Rerun the command in step 2 above and verify that the "nx" parameter is set to "AlwaysOff".

5. Reboot the system to ensure that the "nx" parameter setting takes effect and DEP is disabled.

GENERAL_MSG_CAT_SSL_ERROR]connect to host "" failed: [10054] Connection reset by peer"

"Error -27780: [GENERAL_MSG_CAT_SSL_ERROR]connect to host "" failed: [10054] Connection reset by peer"

 When you are replaying the script in VuGen, sometime you may get the below error.
"Error -27780: [GENERAL_MSG_CAT_SSL_ERROR]connect to host "" failed: [10054] Connection reset by peer"

Application is using SSL version TLSv1, however while running the script from Loadrunner, by default it is sending SSL version SSL2/3. This is the root cause of the problem

To avoid this error, you can follow either one of the steps mentioned below.

a) Include the below statement at the first line of Vuser_init section.

                web_set_sockets_option("SSL_VERSION","TLS"); 

b) In the recording options, Go to Port Mapping -> Options -> Click on "Enable auto SSL detection" and select SSL version as "TLS 1.x". Then Click on Update and save the changes.

Then regenerate the script with the updated settings.

Little's law

Concurrent Users using Little's law

The below real time example will help in deriving the concurrent users using Little's law. In the below example

• Adjusted Hits, Median Think Time derived from production logs for one hour period.
• Avg RT/Step  is the Target Response SLA required to met under load
• No of Steps is no of transactions per business flow
• Concurrent Users is derived using little's law Throughput* (Avg RT+ Think Time)

Performance Counters - Network

Network Throughput

\Network Interface(*)\Bytes Received/sec

The Network Interface Bytes Received/sec shows the Network Received Throughput of the NIC. This is normally displayed in bytes, but we do the calculation when graphing the counter to display it in the standard MB/sec.

Microsoft® Description - Bytes Received/sec is the rate at which bytes are received over each network adapter, including framing characters. Network Interface\Bytes Received/sec is a subset of Network Interface\Bytes Total/sec.

\Network Interface(*)\Bytes Sent/sec

The Network Interface Bytes Sent/sec shows the Network Send Throughput of the NIC. This is normally displayed in bytes, but we do the calculation when graphing the counter to display it in the standard MB/sec.

Microsoft® Description - Bytes Sent/sec is the rate at which bytes are sent over each network adapter, including framing characters. Network Interface\Bytes Sent/sec is a subset of Network Interface\Bytes Total/sec.

Performance counters - Disk

Disk Throughput

The Disk subsystem could be a major system performance bottleneck, because of this we decided to focus on many disk performance counters and present the information by either graphing the total combined counters from all the Disks in the System or to graph the individual disk counters to allow you to pinpoint issues.

\PhysicalDisk(*)\Disk Read Bytes/sec

The Disk Read Bytes/sec shows the Disk Throughput of the Read Operation of the Disk. This is normally displayed in bytes, but we do the calculation when graphing the counter to display it in the standard MB/sec.

Microsoft® Description - Disk Read Bytes/sec is the rate at which bytes are transferred from the disk during read operations.

\PhysicalDisk(*)\Disk Write Bytes/sec

The Disk Write Bytes/sec shows the Disk Throughput of the Write Operation of the Disk. This is normally displayed in bytes, but we do the calculation when graphing the counter to display it in the standard MB/sec.

Microsoft® Description - Disk Write Bytes/sec is rate at which bytes are transferred to the disk during write operations.

Disk Queue Length

There are two main counters for the Disk Queue Length, the Average Disk Queue Length and the Current Disk Queue Length. There are arguments for only using either counter, so to stay out of the debate on which to use, we simply show values for both counters.

\PhysicalDisk(*)\Avg. Disk Queue Length

The Avg. Disk Queue Length counter is the “estimated” average number of requests that are either in process or waiting to be processed by the Disk.
Sustained counters above 5 per Disk could indicate a disk subsystem bottleneck. Remember to also keep an eye on the Pages/sec counter for low memory issues since low memory could cause Disk performance issues if the disk subsystem has to continuously process paging operations.

Microsoft® Description - Avg. Disk Queue Length is the average number of both read and write requests that were queued for the selected disk during the sample interval.

\PhysicalDisk(*)\Current Disk Queue Length

The Current Disk Queue Length counter is the actual number of requests that are either in process or waiting to be processed by the Disk at the time the counter is captured.
Sustained counters above 5 per Disk could indicate a disk subsystem bottleneck. Remember to also keep an eye on the Pages/sec counter for low memory issues since low memory could cause Disk performance issues if the disk subsystem has to continuously process paging operations.

Microsoft® Description - 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. Multi-spindle 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.

Disk Latency and Fragmentation

\PhysicalDisk(*)\Avg. Disk sec/Read

The Avg. Disk sec/Read displays how long in milliseconds it takes for a read operation from the Disk. Watch this counter during times of heavy disk utilization to see if your system would benefit from a more robust Disk Subsystem (such as advanced RAID or newer flash drive technologies).

Microsoft® Description - Avg. Disk sec/Read is the average time, in seconds, of a read of data from the disk.

\PhysicalDisk(*)\Avg. Disk sec/Write

The Avg. Disk sec/Write displays how long in milliseconds it takes for a write operation to the Disk. Watch this counter during times of heavy disk utilization to see if your system would benefit from a more robust Disk Subsystem (such as advanced RAID or newer flash drive technologies).

Microsoft® Description - Avg. Disk sec/Write is the average time, in seconds, of a write of data to the disk.

\PhysicalDisk(*)\Split IO/sec

The Split IO/sec counter displays the physical disk requests that are split into multiple requests. This counter is a primary indicator if a disk is fragmented and needs to be optimized.

Performance Counters CPU/System Stats

CPU/System Stats

In addition to the % Processor Usage counters above, there are additional counters that can detect how the Processor is being worked and if the Processor Subsystem could potentially be a bottleneck.

\Processor(_total)\% Privileged Time

The Processor(_total)\% Privileged Time counter shows the percent of time that the processor is spent executing in Kernel (or Privileged) mode. Privileged mode includes services interrupts inside Interrupt Service Routines (ISRs), executing Deferred Procedure Calls (DPCs), Device Driver calls and other kernel-mode functions of the Windows® Operating System.
Most of the time a processor should be executing User mode operations, a high % privileged time might indicate a poorly written device driver or a faulty piece of hardware.

Microsoft® Description - % 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 other subsystem processes in addition to the privileged time in the process.

\Processor(_total)\% User Time

The Processor(_total)\% User Time counter shows the percent of time that the processor(s) is spent executing in User mode.

Microsoft® Description - % 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.

\System\Processor Queue Length

The Processor Queue Length shows the number of threads that are observed as delayed in the processor Ready Queue and are waiting to be executed.
On single core machines, a sustained value over 5-10 or so may indicate that the workload on the system is more than the processor can handle. On multi-core systems, a good rule of thumb is to divide the Queue Length by the number of cores in the system and use the same indication above with that calculated value.
Note that the Processor Queue Length is an instantaneous counter, whereas the % Processor Usage counters are continuously measured counters that are averaged. There could be some disconnect between these counters because of this.

Microsoft® Description - 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.

Performance Counters - Physical Memory

Physical Memory

The Physical Memory Statistics Graph shows the available Performance Counters for everything that consumes "Physical Memory" on a Windows® Server. In theory, adding all of these counters together should equal the amount of RAM installed, but in practice this does not work. This is the result of Windows ® using shared DLLs and some RAM allocations that are not counted anywhere (such as trimmed working set pages that have yet to be written to disk).

\Memory\Available Bytes

The Available Bytes counter is the pool size of available pages in RAM that the system uses to satisfy requests for new pages. There are multiple counters available for convenience that provide this information, such as Available Mbytes, but this program uses the Available Bytes counter and does the calculation when generating the graphs.
Usually when this value is approximately at least 10% of total system memory, the system has an adequate amount of memory. However when this value is below 10% you must use additional counters, such as Pages/sec to determine if System memory is adequate for the workload.
Note that the "\Memory\Available Bytes" counter is an instantaneous counter (sampled once during the measurement period).

Microsoft® Description - Available Bytes is the amount of physical memory, in bytes, 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.

\Process(_Total)\Working Set

The Working Set counter is the total amount of resident pages allocated in RAM that all the processes that are running on the system can address without causing a Page Fault. The value of this counter is in bytes, but this program does the calculation to MB when it creates the graphs.
Note that the "\Process(_Total)\Working Set" counter is an instantaneous counter (sampled once during the measurement period).

Microsoft® Description - 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.

\Memory\Cache Bytes

The Memory pages that the System uses are counted in two main counters, Cache Bytes and Pool Nonpaged Bytes.
The Cache Bytes counter is the amount of resident pages allocated in RAM that the Kernel threads can address without causing a Page Fault. This counter includes the Pool Paged Resident Bytes, the System Cache Resident Bytes, the System Code Resident Bytes and the System Driver Resident Bytes.
Note that the "\Memory\Cache Bytes" counter is an instantaneous counter (sampled once during the measurement period).

Microsoft® Description - Cache Bytes the size, in bytes, of the portion of the system file cache which is currently resident and active in physical memory. The Cache Bytes and Memory\\System Cache Resident Bytes counters are equivalent. This counter displays the last observed value only; it is not an average.

\Memory\Pool Nonpaged Bytes

The Pool Nonpaged Bytes counter is the amount of resident pages in RAM that the Kernel is using that cannot be paged out.
The Pool Nonpaged Bytes counter is also referred to as "Kernel Memory". If you ever run into any issues with Kernel Memory note that it is extremely difficult to troubleshoot as you have to use Kernel level tools such as "poolmon" to track what is causing the issues.
Also note that Microsoft Windows has limits on how much physical memory can be consumed by Kernel Memory. For instance Windows Server 2008 has a maximum limit of 75% of the amount of Physical Memory. If Kernel Memory reaches that Windows will in fact crash! Refer to the excellent WinInternals reference manuals for more information.
Note that the “\Memory\Pool Nonpaged Bytes” counter is an instantaneous counter (sampled once during the measurement period).

Microsoft® Description - Pool Nonpaged Bytes is the size, in bytes, of the nonpaged pool, an area of the system virtual memory that is used 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(_Total)\\Pool Nonpaged Bytes. This counter displays the last observed value only; it is not an average.

Execute DB queries in loadrunner webservices protocol

Loadrunner web-services protocol can be used to execute DB queries

Action()

{

    int retval;

    int NumRows=0;

   retval = lr_db_connect("StepName=DatabaseConnection",

        "ConnectionString=dsn=Test;userid=test; password=Test",

        "ConnectionName=food",

        "ConnectionType=ODBC",

        LAST );

   

     lr_start_transaction("Report");

 

NumRows = lr_db_executeSQLStatement("StepName=PerformQuery",

    "ConnectionName=foodb",

    "SQLStatement="

    "select count(*) indv_knt, count(distinct lbi_hshl_id) hshl_knt,"

    "count(distinct best_dmid_num) dmid_knt \r\nfrom "

     "CDMZDATAVIEW.best_domestic_postal_addr where ctry_cd = 'US';",

    "DatasetName=MyDataset",

    LAST );

 

   lr_end_transaction("Report", LR_AUTO);

    lr_db_dataset_action("StepName=PrintDataset",

        "DatasetName=MyDataset",

        "Action=PRINT",

         LAST );   

     lr_output_message("The query returned %d rows.", NumRows);

        

  

    

    return 0;

}

RESTful Web Services - Test with loadrunner

Sumilating RESTful web Services using LoadRunner


REST Services can be scripted using web_custom_request by adding appropriate headers using web_add_header function before the web_custom_request.

An example for REST services script is given below.


/*********************************

web_add_header ("X-ELS-APIKey","11111");

web_add_header ("X-Forwarded-For","12.5.28.133");

web_add_header ("Accept","text/xml");

web_custom_request("web_custom_request",

"URL=http://host:8080/content/abstract/*********",

"Method=POST",

"TargetFrame=",

"EncType=text/xml; charset=iso-8859-1",

"Resource=0",

"Referer=",

"Mode=HTTP",

"Body=",

LAST);

*****************************/

If you want to verify the response manually, you need to set up the header values first in your browser.

Please find below the steps for setting up the header using mozilla firefox browser.

• Open firefox. Click "Add-ons" from tools menu
• Click "get Add-ons" tab.
• Type "HTTP header" in the text box for search all add-ons and enter.
• In search results, click on "Add to firefox" for "Modify Headers 0.6.6" and install. Now you can see "Modify Headers 0.6.6" in the extension tab.
• Click on "Modify Headers 0.6.6" from the "Extensions" tab and select the check box for "Always on" and "Open modify header in a new tab" and close.
• Now click "Modify headers" from the firefox tools menu and add the appropriate header name and value for your request.

Now launch the URL in the firefox browser and verify the response manually.

Also refer RESTClient  addon available for firefox to test RESTful services

Analyze Performance Results, Report, and Retest

Managers and stakeholders need more than just the results from various tests — they need conclusions, as well as consolidated data that supports those conclusions. Technical team members also need more than just results — they need analysis, comparisons, and details behind how the results were obtained. Team members of all types get value from performance results being shared more frequently. Before results can be reported, the data must be analyzed. Consider the following important points when analyzing the data returned by your performance test:
Analyze the data both individually and as part of a collaborative, cross-functional technical team.
Analyze the captured data and compare the results against the metric’s acceptable or expected level to determine whether the performance of the application being tested shows a trend toward or away from the performance objectives.
If the test fails, a diagnosis and tuning Step are generally warranted.
If you fix any bottlenecks, repeat the test to validate the fix.
Performance-testing results will often enable the team to analyze components at a deep level and correlate the information back to the real world with proper test design and usage analysis.
Performance test results should enable informed architecture and business decisions.
Frequently, the analysis will reveal that, in order to completely understand the results of a particular test, additional metrics will need to be captured during subsequent test-execution cycles.
Immediately share test results and make raw data available to your entire team.
Talk to the consumers of the data to validate that the test achieved the desired results and that the data means what you think it means.
Modify the test to get new, better, or different information if the results do not represent what the test was defined to determine.
Use current results to set priorities for the next test.
Collecting metrics frequently produces very large volumes of data. Although it is tempting to reduce the amount of data, always exercise caution when using data-reduction techniques because valuable data can be lost. Most reports fall into one of the following two categories:
Technical Reports
Description of the test, including workload model and test environment.
Easily digestible data with minimal pre-processing.
Access to the complete data set and test conditions.
Short statements of observations, concerns, questions, and requests for collaboration.
Stakeholder Reports
Criteria to which the results relate.
Intuitive, visual representations of the most relevant data.
Brief verbal summaries of the chart or graph in terms of criteria.
Intuitive, visual representations of the workload model and test environment.
Access to associated technical reports, complete data sets, and test conditions.
Summaries of observations, concerns, and recommendations. The key to effective reporting is to present information of interest to the intended audience in a manner that is quick, simple, and intuitive. The following are some underlying principles for achieving effective reports:
Report early, report often.
Report visually.
Report intuitively.
Use the right statistics.
Consolidate data correctly.
Summarize data effectively.
Customize for the intended audience.
Use concise verbal summaries using strong but factual language.
Make the data available to stakeholders.
Filter out any unnecessary data.
If reporting intermediate results, include the priorities, concerns, and blocks for the next several test-execution cycles.

http://perftesting.codeplex.com/Wiki/View.aspx?title=How%20To%3A%20Conduct%20Performance%20Testing%20Core%20Steps%20for%20a%20Web%20Application

Source - Microsoft book

Execute the Performance Test

Executing tests is what most people envision when they think about performance testing. It makes sense that the process, flow, and technical details of test execution are extremely dependent on your tools, environment, and project context. Even so, there are some fairly universal tasks and considerations that need to be kept in mind when executing tests.Much of the performance testing–related training available today treats test execution as little more than starting a test and monitoring it to ensure that the test appears to be running as expected. In reality, this Step is significantly more complex than just clicking a button and monitoring machines. Test execution can be viewed as a combination of the following sub-tasks:
Coordinate test execution and monitoring with the team.
Validate tests, configurations, and the state of the environments and data.
Begin test execution.
While the test is running, monitor and validate scripts, systems, and data.
Upon test completion, quickly review the results for obvious indications that the test was flawed.
Archive the tests, test data, results, and other information necessary to repeat the test later if needed.
Log start and end times, the name of the result data, and so on. This will allow you to identify your data sequentially after your test is done. As you prepare to begin test execution, it is worth taking the time to double-check the following items:
Validate that the test environment matches the configuration that you were expecting and/or designed your test for.
Ensure that both the test and the test environment are correctly configured for metrics collection.
Before running the real test, execute a quick smoke test to make sure that the test script and remote performance counters are working correctly. In the context of performance testing, a smoke test is designed to determine if your application can successfully perform all of its operations under a normal load condition for a short time.
Reset the system (unless your scenario calls for doing otherwise) and start a formal test execution.
Make sure that the test scripts’ execution represents the workload model you want to simulate.
Make sure that the test is configured to collect the key performance and business indicators of interest at this time.
Source - Microsoft book

Implement the Performance Test Design

The details of creating an executable performance test are extremely tool-specific. Regardless of the tool that you are using, creating a performance test typically involves scripting a single usage scenario and then enhancing that scenario and combining it with other scenarios to ultimately represent a complete workload model. Load-generation tools inevitably lag behind evolving technologies and practices. Tool creators can only build in support for the most prominent technologies and, even then, these have to become prominent before the support can be built. This often means that the biggest challenge involved in a performance-testing project is getting your first relatively realistic test implemented with users generally being simulated in such a way that the application under test cannot legitimately tell the difference between the simulated users and real users. Plan for this and do not be surprised when it takes significantly longer than expected to get it all working smoothly.
Source - Microsoft books

Configure the Performance Test Environment

Preparing the test environment, tools, and resources for test design implementation and test execution prior to features and components becoming available for test can significantly increase the amount of testing that can be accomplished during the time those features and components are available.Load-generation and application-monitoring tools are almost never as easy to get up and running as one expects. Whether issues arise from setting up isolated network environments, procuring hardware, coordinating a dedicated bank of IP addresses for IP spoofing, or version compatibility between monitoring software and server operating systems, issues always seem to arise from somewhere. Start early, to ensure that issues are resolved before you begin testing.Additionally, plan to periodically reconfigure, update, add to, or otherwise enhance your load-generation environment and associated tools throughout the project. Even if the application under test stays the same and the load-generation tool is working properly, it is likely that the metrics you want to collect will change. This frequently implies some degree of change to, or addition of, monitoring tools.
Source - Microsoft books

Plan and Design Tests

Planning and designing performance tests involves identifying key usage scenarios, determining appropriate variability across users, identifying and generating test data, and specifying the metrics to be collected. Ultimately, these items will provide the foundation for workloads and workload profiles. When designing and planning tests with the intention of characterizing production performance, your goal should be to create real-world simulations in order to provide reliable data that will enable your organization to make informed business decisions. Real-world test designs will significantly increase the relevancy and usefulness of results data. Key usage scenarios for the application typically surface during the process of identifying the desired performance characteristics of the application. If this is not the case for your test project, you will need to explicitly determine the usage scenarios that are the most valuable to script. Consider the following when identifying key usage scenarios:
Contractually obligated usage scenario(s)
Usage scenarios implied or mandated by performance-testing goals and objectives
Most common usage scenario(s)
Business-critical usage scenario(s)
Performance-intensive usage scenario(s)
Usage scenarios of technical concern
Usage scenarios of stakeholder concern
High-visibility usage scenarios When identified, captured, and reported correctly, metrics provide information about how your application’s performance compares to your desired performance characteristics. In addition, metrics can help you identify problem areas and bottlenecks within your application. It is useful to identify the metrics related to the performance acceptance criteria during test design so that the method of collecting those metrics can be integrated into the tests when implementing the test design. When identifying metrics, use either specific desired characteristics or indicators that are directly or indirectly related to those characteristics.

Source - Microsoft book

Identify Performance Acceptance Criteria

It generally makes sense to start identifying, or at least estimating, the desired performance characteristics of the application early in the development life cycle. This can be accomplished most simply by noting the performance characteristics that your users and stakeholders equate with good performance. The notes can be quantified at a later time. Classes of characteristics that frequently correlate to a user’s or stakeholder’s satisfaction typically include:
Response time. For example, the product catalog must be displayed in less than three seconds.
Throughput. For example, the system must support 25 book orders per second.
Resource utilization. For example, processor utilization is not more than 75 percent. Other important resources that need to be considered for setting objectives are memory, disk input/output (I/O), and network I/O.
Source - Microsoft books

Identify the Performance Test Environment

The environment in which your performance tests will be executed, along with the tools and associated hardware necessary to execute the performance tests, constitute the test environment. Under ideal conditions, if the goal is to determine the performance characteristics of the application in production, the test environment is an exact replica of the production environment but with the addition of load-generation and resource-monitoring tools. Exact replicas of production environments are uncommon. The degree of similarity between the hardware, software, and network configuration of the application under test conditions and under actual production conditions is often a significant consideration when deciding what performance tests to conduct and what size loads to test. It is important to remember that it is not only the physical and software environments that impact performance testing, but also the objectives of the test itself. Often, performance tests are applied against a proposed new hardware infrastructure to validate the supposition that the new hardware will address existing performance concerns.The key factor in identifying your test environment is to completely understand the similarities and differences between the test and production environments. Some critical factors to consider are:
Hardware
Configurations
Machine hardware (processor, RAM, etc.)
Network
Network architecture and end-user location
Load-balancing implications
Cluster and Domain Name System (DNS) configurations
Tools
Load-generation tool limitations
Environmental impact of monitoring tools
Software
Other software installed or running in shared or virtual environments
Software license constraints or differences
Storage capacity and seed data volume
Logging levels
External factors
Volume and type of additional traffic on the network
Scheduled or batch processes, updates, or backups
Interactions with other systems
Source from microsoft book

Core Performance-Testing Steps

The seven core performance-testing Steps can be summarized as follows.

Step 1. Identify the Test Environment.
Step 2. Identify Performance Acceptance Criteria
Step 3. Plan and Design Tests.
Step 4. Configure the Test Environment.
Step 5. Implement the Test Design.
Step 6. Execute the Test.
Step 7. Analyze Results, Report, and Retest.

What are Vusers

Load generators are controlled by VuGen scripts which issue non-GUI API calls using the same protocols as the client under test. But WinRunner GUI Vusers emulate keystrokes, mouse clicks, and other User Interface actions on the client being tested Only one GUI user can run from a machine unless LoadRunner Terminal Services Manager manages remote machines with Terminal Server Agent enabled and logged into a Terminal Services Client session.
During run-time, threaded vusers share a common memory pool. So threading supports more Vusers per load generator.
The Status of Vusers on all load generators start from "Running", then go to "Ready" after going through the init section of the script. Vusers are "Finished" in passed or failed end status. Vusers are automatically "Stopped" when the Load Generator is overloaded.

Source from Wilsomar notes

Loadrunner Architecture

LoadRunner works by creating virtual users who take the place of real users operating client software, such as IE sending requests using the HTTP protocol to IIS or Apache web servers.
Requests from many virtual user clients are generated by "Load Generators" in order to create a load on servers.
These load generator agents are started and stopped by Mercury's "Controller" program.
The Controller controls load test runs based on "Scenarios" invoking compiled "Scripts" and associated "Run-time Settings".
Scripts are crafted using Mercury's "Virtual user script Generator" (named "V U Gen"), It generates C-language script code to be executed by virtual users by capturing network traffic between Internet application clients and servers.
During runs, the status of each machine is monitored by the Controller.
At the end of each run, the Controller combines its monitoring logs with logs obtained from load generators, and makes them available to the "Analysis" program, which can then create run result reports and graphs for Microsoft Word, Crystal Reports, or an HTML webpage browser.
Each HTML report page generated by Analysis includes a link to results in a text file which