Prerequisites for load Testing in load runner

Important Set up before load testing includes:

A suitable time to load-test the application, for instance when no development work is taking place on the server (load testing may cause the server to crash) and/or no other users are accessing the server (else the testing results would not yield the correct measures)

1.  The performance metrics, accepted levels, or SLAs and goals
2.  Objectives of the test
3.  The Internet protocol(s) the application is(are) using (HTTPS, HTTP, FTP, etc.)
4. If your application has a state, the method used to manage it (URL rewriting, cookies, etc.)
5.  The workload at normal time and at peak time
6. Before load or performance testing application should be stable at least tested at once through the manual method
7. Before load testing, do not record any page, which has 404 or server errors
8. During load test don’t do real transaction or any money ready work.
9.  During load testing try to maintain the real scenario as user experience
10.  Use meaningful test scenarios (use cases are helpful) to construct test plans with 'real-life' test cases.
11.  Make sure that the machine running Load testing tool has sufficient network bandwidth, so the network connection has little to no impact on the results.
12.  Let Load Test run for long time periods, hours or days, or for a large number of iterations. This may yield a smaller standard deviation, giving better average results. In addition, this practice may test system availability rate and may highlight any decay in server performance.
13.  Ensure that the application is stable and optimized for one user before testing it for concurrent users.
14.  Incorporate 'thinking time' or delays using Timers in your Load testing scenario Test Plan. 
15.  Keep a close watch on the four main things: processor, memory, disk, and network.
16.  Only run Load testing tool against servers that you are assigned to test, else you may be accused of causing DoS attacks.

How to check vuser status per script in Analysis in Load runner

To check vuser status (i.e. passed/failed/stopped) per script perform the following: 

1. Analyse the results in Analysis
2. Open the Vuser Summary graph.
3. Right-click on the graph, select "Set filter," then select the script name.
4. Select the Vuser End Status that you are interested in (Passed/Failed/Error/Stopped).

Enable remote desktop connection from remote registry

Machine A : PC which you are using to active remote desktop connection in another PC

Machine B : PC for which remote desktop connection has to be activated.

Step 1: From Machine A : Goto Start -> Run -> regedit. Open the Registry window of Machine A.

(Note: User ID logged in Machine A should have ADMIN rights in Machine B)

Step 2: Click “Connect Network Registry“

Step 3:Enter the computer name of Machine B, for which we have to change the settings and Click “OK”

Step4:The destination machine (Machine B) will be connected with our current logged in machine (Machine A).

Step 5:Goto the below mentioned path and change the fDenyTSConnections to “0” and click “OK”.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

Step 6:After doing the following changes, right-click the remote machine (Machine B) name and click Disconnect.

NOTE: If suppose the above mentioned registry value is not found, then create a DWORD parameter with a value ’0′.

What is Little's law?

Little's Law:

Little's law is quite simple and intuitively appealing.

The law states that the average number of customers in a system (over some time interval), N, is equal to their average arrival rate, X, multiplied by their average time in the system, R.

N = X . R (or) for easy remembrance use L = A . W

This law is very important to check whether the load testing tool is not a bottleneck.
For Example, in a shop , if there are always 2 customers available at the counter queue , wherein the customers are entering the shop at the rate of 4 per second , then time taken for the customers to leave from the shop can be calculated as

N = X. R
R = 2/4 = 0.5 seconds

A Simple example of how to use this law to know how many virtual users licenses are required:

Web system that has peak user load per hour = 2000 users
Expected Response time per transaction = 4 seconds
The peak page hits/sec = 80 hits/sec

For carrying out Performance tests for the above web system, we need to calculate how many number of Virtual user licenses we need to purchase.

N = X . R
N = 80 . 4 = 320

Therefore 320 virtual user licenses are enough to carry out the Load Test.

How transaction response time is different from Hits Per Seconds in load runnner

Hits per Seconds is the number of hits made to the web server. These hits can be requests made to the web server for data or graphics. Hits per second measures the number of times the web server is being accessed. So, it does not represent well to users on how well their applications is performing.

Transaction Response Time helps us to find performance bottlenecks in the application. We can further drill down by correlation using other measurements such as the number of virtual users that is accessing the application at the time of measurement. Other system related metrics like CPU Utilization etc. can be used to identify the root cause.

In LoadRuner, after running a performance test, various measurements can be correlated to find trends and bottlenecks. Correlation can be done between the response time, the amount of load that was generated and the payload of all the components of the application.

How transaction response time is different from Hits Per Seconds in load runnner

Hits per Seconds is the number of hits made to the web server. These hits can be requests made to the web server for data or graphics. Hits per second measures the number of times the web server is being accessed. So, it does not represent well to users on how well their applications is performing.

Transaction Response Time helps us to find performance bottlenecks in the application. We can further drill down by correlation using other measurements such as the number of virtual users that is accessing the application at the time of measurement. Other system related metrics like CPU Utilization etc. can be used to identify the root cause.

In LoadRuner, after running a performance test, various measurements can be correlated to find trends and bottlenecks. Correlation can be done between the response time, the amount of load that was generated and the payload of all the components of the application

How transaction response time effects the performance of application?

How can we use Transaction Response Time to analyze performance issue?
Transaction Response Time allows us to identify abnormalities when performance issues surface. This will be represented as slow response of the transaction, which differs significantly (or slightly) from the average of the Transaction Response Time.

With this, we can further drill down by correlation using other measurements such as the number of virtual users that is accessing the application at the point of time and the system-related metrics (e.g. CPU Utilization) to identify the root cause.

Bringing all the data that have been collected during the load test, we can correlate the measurements to find trends and bottlenecks between the response time, the amount of load that was generated and the payload of all the components of the application.

How is it beneficial to the Project Team?

Using Transaction Response Time, Project Team can better relate to their users using transactions as a form of language protocol that their users can comprehend. Users will be able to know that transactions (or business processes) are performing at an acceptable level in terms of time.

Users may be unable to understand the meaning of CPU utilization or Memory usage and thus using a common language of time is ideal to convey performance-related issues.

What is Transaction Response Time?How it is calculated by the tool Load runner

Transaction Response Time represents the time taken for the application to complete a defined transaction or business process.

Why is important to measure Transaction Response Time?
The objective of a performance test is to ensure that the application is working perfectly under load. However, the definition of “perfectly” under load may vary with different systems.
By defining an initial acceptable response time, we can benchmark the application if it is performing as anticipated.

The importance of Transaction Response Time is that it gives the project team/ application team an idea of how the application is performing in the measurement of time. With this information, they can relate to the users/customers on the expected time when processing request or understanding how their application performed.

What does Transaction Response Time encompass?

The Transaction Response Time encompasses the time taken for the request made to the web server, there after being process by the Web Server and sent to the Application Server. Which in most instances will make a request to the Database Server. All this will then be repeated again backward from the Database Server, Application Server, Web Server and back to the user. Take note that the time taken for the request or data in the network transmission is also factored in.

To simplify, the Transaction Response Time comprises of the following:

• Processing time on Web Server
• Processing time on Application Server
• Processing time on Database Server
• Network latency between the servers, and the client

The following diagram illustrates Transaction Response Time.

Figure 1

Transaction Response Time = (t1 + t2 + t3 + t4 + t5 + t6 + t7 + t8 + t9) X 2
Note:Factoring the time taken for the data to return to the client.

How do we measureransation Response Time?Measuring of the Transaction Response Time begins when the defined transaction makes a request to the application. From here, till the transaction completes before proceeding with the next subsequent request (in terms of transaction), the time is been measured and will stop when the transaction completes.

Differences with Hits Per Seconds and Transaction Response timesHits per Seconds measures the number of “hits” made to a web server. These “hits” could be a request made to the web server for data or graphics. However, this counter does not represent well to users on how well their applications is performing as it measures the number of times the web server is being accessed.

How can we use Transaction Response Time to analyze performance issue?
Transaction Response Time allows us to identify abnormalities when performance issues surface. This will be represented as slow response of the transaction, which differs significantly (or slightly) from the average of the Transaction Response Time.

With this, we can further drill down by correlation using other measurements such as the number of virtual users that is accessing the application at the point of time and the system-related metrics (e.g. CPU Utilization) to identify the root cause.

Bringing all the data that have been collected during the load test, we can correlate the measurements to find trends and bottlenecks between the response time, the amount of load that was generated and the payload of all the components of the application.

How is it beneficial to the Project Team?

Using Transaction Response Time, Project Team can better relate to their users using transactions as a form of language protocol that their users can comprehend. Users will be able to know that transactions (or business processes) are performing at an acceptable level in terms of time.

Users may be unable to understand the meaning of CPU utilization or Memory usage and thus using a common language of time is ideal to convey performance-related issues.

LR Controller online Graphs Directory to modify

1. By default, the Controller online monitor shows a maximum of 20 measurements for each graph. To increase it, go to the LoadRunner\dat\online_graphs directory to modify the value ofMaxDispMeasurments= in the file controlling each type of graph: 

2. Default counters for the System Resource, Microsoft IIS, Microsoft ASP, or SQL Server monitors are defined in the res_mon.dft file within the LoadRunner/dat folder. Its values can be pasted from the [MonItemPlus] section within scenario .lrs files.

Description	File Name
All	generalsettings.ini
System Resource Graphs	online_resource_graphs.rmd
Runtime Graphs	online_runtime_graphs.def
Transaction Graphs	online_transaction_graphs.def
Web Resource Graphs	online_web_graphs.def
Streaming Media	online_web_graphs_mms.def

What is Soak testing?

Soak testing is running a system at high levels of load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day (or night) than would be expected in a busy day, to identify any performance problems that appear after a large number of transactions have been executed.

Also, it is possible that a system may ‘stop’ working after a certain number of transactions have been processed due to memory leaks or other defects. Soak tests provide an opportunity to identify such defects, whereas load tests and stress tests may not find such problems due to their relatively short duration.



The above diagram shows activity for a certain type of site. Each login results in an average session of 12 minutes duration with and average eight business transactions per session.

A soak test would run for as long as possible, given the limitations of the testing situation. For example, weekends are often an opportune time for a soak test. Soak testing for this application would be at a level of 550 logins per hour, using typical activity for each login.

The average number of logins per day in this example is 4,384 per day, but it would only take 8 hours at 550 per hour to run an entire days activity through the system.

By Starting a 60 hour soak test on Friday evening at 6 pm (to finish at 6am Monday morning), 33,000 logins would be put through the system, representing 7½ days of activity. Only with such a test, will it be possible to observe any degradation of performance under controlled conditions. 

Some typical problems identified during soak tests are listed below: 
Serious memory leaks that would eventually result in a memory crisis, Failure to close connections between tiers of a multi-tiered system under some circumstances which could stall some or all modules of the system. 

Failure to close database cursors under some conditions which would eventually result in the entire system stalling. Gradual degradation of response time of some functions as internal data-structures become less efficient during a long test.

Apart from monitoring response time, it is also important to measure CPU usage and available memory. If a server process needs to be available for the application to operate, it is often worthwhile to record it's memory usage at the start and end of a soak test. It is also important to monitor internal memory usages of facilities such as Java Virtual Machines, if applicable.

Long Session Soak Testing
When an application is used for long periods of time each day, the above approach should be modified, because the soak test driver is not Logins and transactions per day, but transactions per active user for each user each day.

This type of situation occurs in internal systems, such as ERP and CRM systems, where users login and stay logged in for many hours, executing a number of business transactions during that time. A soak test for such a system should emulate multiple days of activity in a compacted time-frame rather than just pump multiple days worth of transactions through the system.

Long session soak tests should run with realistic user concurrency, but the focus should be on the number of transactions processed. VUGen scripts used in long session soak testing may need to be more sophisticated than short session scripts, as they must be capable of running a long series of business transactions over a prolonged period of time.
Test Duration

The duration of most soak tests is often determined by the available time in the test lab. There are many applications, however, that require extremely long soak tests. Any application that must run, uninterrupted for extended periods of time, may need a soak test to cover all of the activity for a period of time that is agreed to by the stakeholders, such as a month. Most systems have a regular maintenance window, and the time between such windows is usually a key driver for determining the scope of a soak test.

A classic example of a system that requires extensive soak testing is an air traffic control system. A soak test for such a system may have a multi-week or even multi-month duration.