LoadRunner Architecture Overview .

LoadRunner works by creating virtual users who take the place of real users operating client software, such as Internet Explorer  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 various servers under test

These load generator agents are started and stopped by the "Controller" program.

The Controller controls load test runs based on "Scenarios" invoking compiled "Scripts" and associated "Run-time Settings".

Scripts are crafted using the "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.

With Java clients, VuGen captures calls by hooking within the client JVM.

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 Microsoft Excel can open to perform additional analysis.

HP LoadRunner

HP LoadRunner is an automated performance and testing product from Hewlett-Packard for examining system behavior and performance, while generating actual load. HP acquired LoadRunner as part of its acquisition of Mercury Interactive in November 2006. HP LoadRunner can simulate hundreds or thousands of concurrent users to put the application through the rigors of real-life user loads, while collecting information from key infrastructure components (Web servers, database servers etc. The results can then be analyzed in detail, to explore the reasons for particular behavior. HP LoadRunner is sold as part of the HP IT Management Software category by the HP Software Division.

Consider the client-side application for an automated teller machine (ATM). Although each client is connected to a server, hundreds of ATMs may be open to the public. During peak times — such as 10 a.m. Monday, the start of the work week — the load may be much higher than normal. In order to test such situations, it is not practical to have a test bed of hundreds of ATMs. So, one can use an ATM simulator and a computer system with HP LoadRunner to simulate a large number of users accessing the server simultaneously. Once activities are defined, they are repeatable. After debugging a problem in the application, managers can check whether the problem persists by reproducing the same situation, with the same type of user interaction.

HP LoadRunner consists of several different tools: Virtual User Generator (VuGen), Controller, Load Generator, and Analysis.

Furthermore, LoadRunner supports a very wide variety of application protocols; this allows LoadRunner to natively support many types of applications, including those based on Web technologies, Flex AMF, Citrix ICA, Remote Desktop Protocol (RDP), ERP/CRM (e.g. SAP, Oracle eBusiness, Siebel and PeopleSoft), Databases, Mail Clients, Web Services, and many more. Recently, AJAX Tru Client was introduced (new with V.11.0), that provides LoadRunner with next-gen web application support.

Licensing is based on a number of variables, including the number of concurrent load test users, the number of controllers, as well as the type of protocols utilized.

Additionally, HP Performance Center is available for larger installations; adding central administration, team management and resource pooling capabilities

Load Balancing Environment.

Application Architecture.

Entry Criteria for Performance testing.

1) Application functionally should be stable, functional testing should be completed.

2) All the performance objectives and parameters are defined.

3) Performance Test environment setup provided is functionally stable, and to the

        simulate Production environment as close as possible 

4) Test User ID’s and other access related authentications are provided in time to the 

        performance Testing team. 

5) Proper privileges are given the User ID’s

6) Performance critical workflows and test scenarios are provided to the Performance 

        test team

7) Load runner components are installed properly in the identified machines.

8) Access to all application and performance critical applications are provided

Stand Alone or Desktop based Application & Objectives.

The application which runs only through a client layer is called desktop based applications, ex: notepad, calculator etc.

Objectives:
1) Response time

Desktop application runs on personal computers and work stations, so when you test the desktop application you are focusing on a specific environment. You will test complete application broadly in categories like GUI, functionality, Load, and backend i.e. DB.

Client Server Based Application Architecture & Objectives.

The client/server model is a computing model that acts as a distributed application which partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients. Often clients and servers communicate over a computer network on separate hardware, but both client and server may reside in the same system. A server machine is a host that is running one or more server programs which share their resources with clients. A client does not share any of its resources, but requests a server's content or service function. Clients therefore initiate communication sessions with servers which await incoming requests.

The application which communicates between client and data based server is called client server based application.

Objectives:

1) Response time

2) DB server behavior 

3) Vusers load

In client server application you have two different components to test. Application is loaded on server machine while the application exe on every client machine. You will test broadly in categories like, GUI on both sides, functionality, Load, client-server interaction, backend. This environment is mostly used in Intranet networks. You are aware of number of clients and servers and their locations in the test scenario.

Web Based Application Architecture & Objectives.

Web application is an application that is accessed by users over a network such as the Internet or an intranet. The term may also mean a computer software application that is coded in a browser-supported language (such as JavaScript, combined with a browser-rendered markup language like HTML) and reliant on a common web browser to render the application executable.

Web applications are popular due to the ubiquity of web browsers, and the convenience of using a web browser as a client, sometimes called a thin client. The ability to update and maintain web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity, as is the inherent support for cross-platform compatibility. Common web applications include webmail, online retail sales, online auctions, wikis and many other functions.

 The application which runs based up on the web server is called web based application

Objectives:

1) Response time

2) Servers behavior

3) Network bandwidth

4) Vusers load

Web application is a bit different and complex to test as tester don’t have that much control over the application. Application is loaded on the server whose location may or may not be known and no exe is installed on the client machine, you have to test it on different web browsers. Web applications are supposed to be tested on different browsers and OS platforms so broadly Web application is tested mainly for browser compatibility and operating system compatibility, error handling, static pages, backend testing and load testing.

Performance Goals & Objectives.

The primary objective of performance testing test is to measure the response time of each user action.

Speed – Determines whether the application responds quickly

Scalability – Determines maximum user load the software application can handle.

Stability – Determines if the application is stable under varying loads

Performance testing can serve different purposes.

 It can demonstrate that the system meets performance criteria.

 It can compare two systems to find which performs better.

     Or it can measure what parts of the system or workload causes the system to perform         badly.

Why do Performance testing?

Performance testing is done to provide stakeholders with information about their application regarding speed, stability and scalability. More importantly, performance testing uncovers what needs to be improved before the product goes to market. Without performance testing, software is likely to suffer from issues such as: running slow while several users use it simultaneously, inconsistencies across different operating systems and poor usability. Performance testing will determine whether or not their software meets speed, scalability and stability requirements under expected workloads. Applications sent to market with poor performance metrics due to nonexistent or poor performance testing are likely to gain a bad reputation and fail to meet expected sales goals. Also, mission critical applications like space launch programs or life saving medical equipments should be performance tested to ensure that they run for a long period of time without deviations

What is Performance testing?

In software engineering, performance testing is in general testing performed to determine how a system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage.

Performance testing is a subset of performance engineering, an emerging computer science practice which strives to build performance into the implementation, design and architecture of a system

Software Development Life cycle

Performance Testing life cycle

Performance Questionnaires

The following are the basic set of requirements for performance testing of any application:

A. Application Questionnaire

1.      Description of the Application, various modules (if application is structured in a modular fashion), its functionalities, etc. The points to be covered are: -

• General Description, Functional flow of the application.
• System Architecture  (Communication flow)
• Interface Description (if the system architecture involves interfacing to other subsystems) 
1. Technical architecture of application under test with various technologies involved in the design of the application and other subsystems.

3.      Various protocols (ex: web, Siebel, oracle ..etc) supported (any specific proprietary protocols, if expected to be supported should be

4. If the application has been developed provide the URL of an environment close to the production environment on which tests could be performed.
5. Platforms/OS/Database supported/recommended for the product/application.
6. List of frequently used functionalities in the application/system/product.
7. List of business critical functionalities in the application/system/.
8. Workload Model for the application system

(This involves the description of the usage of various functionalities/modules of the application/system/product in the production or real environment. More particularly, the number of users using various functionalities or modules of the application/system in a day or over a period of time) what are the various profiles and their frequency of activities on the site? Also provide the peak load that can be expected from each user profile and the duration for which the peak load is to be maintained. 

9.      Whether the SLA’s have been defined? Please provide the SLA’s details

10.  What is the maximum concurrent users using the site? 

11.  What is the maximum load that you want to generate on the system? 

12.  If the application is already in production what is the user profile (Peak hour load, Normal hour load).

13. Are there any monitoring over firewalls and /or remote load generator builds
14. Please mention details of monitoring, e.g. oracle and web/app servers 
15. Any benchmark available for the performance of the application functions or subsystems 
16. Baseline details (Client expectations) 

B. Engagement Questionnaire:

 Tentative Start Date of the Project

A.    Planned Completion Date of the Project 

C. Tool Questionnaire:

A.    Does the client has licensed tool for performance testing, If yes please provide the details of the tool.

B.     If the Client has license for Load runner tool, are Load Generators placed at different regions?

(To simulate real time load)

C.     Does client has remote desktop software so that users can access the machines located at?

D. Resources Questionnaire: 

A.    Does the client will provide DBA support/Infra/Dev/Web admin during the execution of Load test?

B.     Number of Resources required at Onsite and Offshore.

D.    Define Pass / Fail Criteria (What is acceptable performance parameter)

F. Contacts for Issues and escalations:

     (Infra team, Database team, Dev team, Web admin team)

G. Comments (If Any)