Working with Firewalls in Loadrunner

Working with a firewall means that you can prevent unauthorized access to or from a private network, on specific port numbers.

In a regular LoadRunner load test scenario (not over a firewall), the Controller has direct access to the LoadRunner agents running on remote machines. This enables the Controller to connect directly to those machines. When running Vusers or monitoring applications over a firewall, this direct connection is blocked by the firewall. The connection cannot be established by the Controller, because it does not have permissions to open the firewall.

LoadRunner solves this problem by using a communication configuration based on HTTPS or secured TCP/IP. This configuration uses the standard SSL port on the firewall (port 443).

A LoadRunner agent is installed on load generators running Vusers over a firewall, and on Monitor Over Firewall machines that monitor the servers that are located over a firewall. The agent communicates with the MI Listener machine through port 443 in the firewall. The MI Listener is a component that serves as router between the Controller and the LoadRunner agent.

When the LoadRunner agent connects to the MI Listener, the MI Listener keeps a listing of the connection to the agent using a symbolic name that the agent passed to it. When the Controller connects to the MI Listener, it communicates to the MI Listener through port 50500.

Setting Up your System to Use Firewalls:

Basic Steps Setting up your system to use firewalls involves the following stages of configuration: Installation and initial configuration Running Vusers over a firewall Installation and initial configuration

To enable over-firewall communication, ensure that you have installed the following LoadRunner components:

MI Listener Monitor Over Firewall component To perform initial configuration of your over-firewall system:

1 Configure your system according to TCP or HTTPS.

2 Modify your firewall settings to enable communication between the machines on either side of the firewall.

3 Configure the MI Listener.

Configuring the MI Listener To configure the MI Listener:

1 Open incoming HTTPS service for port 443. The port settings are set by your system administrator.

2 Stop the LoadRunner agent on the MI Listener machine by right-clicking its icon in the system tray and selecting Close from the popup menu.

3 Run MI Listener Configuration from Start > Programs > LoadRunner > Advanced Settings, or run \launch_service\bin\MILsnConfig.exe.

4 Set each option as described in the following table:

5 Click OK to save your changes, Cancel to cancel them, or Use Defaults.

6 Restart the LoadRunner agent by double-clicking the shortcut on the desktop, or choosing Start > Programs > LoadRunner.

7 Make sure that port 443 is free on the MI Listener machine.

Running Vusers over a firewall

To set up your system to run Vusers over a firewall:

1 On each load generator machine that will be running over a firewall, configure the LoadRunner agent to communicate with the MI Listener.

2 Configure the Controller machine to recognize the load generator and MI Listener machines.

Configuring LoadRunner Agents Over the Firewall

1 Stop the LoadRunner agent by right-clicking its icon in the system tray and selecting Close.

2 Run Agent Configuration from Start > Programs > LoadRunner > Advanced Settings, or run \launch_service\bin\AgentConfig.exe.

3 Select the Enable Firewall Agent check box, and then click Settings. The Agent Configuration dialog box opens.

4 Set each option as described in “Agent Configuration Settings”

5 Click OK to save your changes, or Cancel to cancel them.

6 Restart the LoadRunner agent by double-clicking the shortcut on the desktop, or select Start > Programs > LoadRunner > LoadRunner Agent Service/Process.

7 Check the connection status between the LoadRunner agent and the MI Listener.

Configuring the Controller for Running over a Firewall

1 Run the Controller from Start > Programs > LoadRunner > Applications > Controller and create a new scenario, or load an existing one.

2 Click Generators to display the Load Generators window. In the Name field, enter the symbolic name of the server. This is the same name that you entered in the Local Machine Key setting in the Agent Configuration.

3 Select the Load Generator, and click Details to display the Load Generator Information.

4 In the Security tab, enter the MI Listener machine’s name in the MI Listener field. This is the same name that you entered in the MI Listener Name setting of the Agent Configuration dialog box. In this example, the MI Listener is bunji.

5 In the Firewall Settings section, select one of the following options: ➤ Enable running Vusers over Firewall. To run Vusers over the firewall. ➤ Enable Monitoring over Firewall. To monitor Vusers over the firewall.

6 Click OK to return to the Load Generators dialog box.

7 Select the load generator and click Connect. This will do all the setup required to run your test over the firewall…

VSTS 2005/2008 – Environment Setup

Load Agent and Load Controller Installation and Configuration Guide

All Microsoft® Visual Studio 2005 Team Test Load Agent Products

The Team Test Rig enables Team System users to run tests on one or more remote computers. A rig is made up of a single test controller and one or more test agents. The test controller can be installed on either one or two computers, and like Team Foundation Server, has both application and data tiers. A single test controller is used to coordinate the execution of multiple test agents running tests on multiple computers.

 

Lab Setup for Remote Load Testing

 

 

Supported Operating Systems

The following operating systems are supported for the agent and controller:

 

Controller	Windows Server 2003 (RTM) Note   Load controllers cannot be installed on domain controllers. Windows XP Professional (SP2)
Agent	Windows Server 2003 (RTM) Windows XP Professional (SP2) Windows 2000 (SP4)

 

Hardware Requirements

For the test agent, memory and CPU typically control how much load can be generated. The test controller does not generate load, but does collect load test statistics from the agents and performance counter data from the agents and system under test. Therefore, database used by the controller requires considerable resources both for the amount of data stored and the number of agents involved in the load test scenario. Use the following table as a guide for determining hardware requirements for the controller and agent:

 

	Controller Application Tier		Controller Data Tier		Controller Application/Data Tier
	Min	Recommended	Min	Recommended	Min	Recommended
CPU	600 Mhz	1 GHz	600 Mhz	1 GHz	600 Mhz	1 GHz
Disk – system	1 GB	1 GB	1 GB	1 GB	1 GB	1 GB
Disk – install	1 GB	8 GB	8 GB	40 GB	8GB	48 GB
Memory	256 MB	512 MB	512 MB	1 GB	512 MB	1 GB

 

Agent	Minimum	Recommended
CPU	600 MHz	2 GHz
Disk – system	1 GB	1 GB
Disk – install	1 GB	5 GB
Memory	256 MB	1 GB

 

By default, SQL Express is installed with the controller and is used as the default store for load test results. Therefore, the controller runs an instance of SQL Express.  For more information, see “SQL Sizing Considerations” later in this document.

Supported Configurations

Visual Studio, the Test Controller, SQL, and the Test Agent can all reside on the same computer or be installed on different computers. Typical computer configurations are:

Recommended Configuration:

· Computer 1: Visual Studio

· Computer 2: Controller, SQL Express

· Computer 3-n: Agents

Note   Installing an agent on the same computer as the controller can interfere with results collection. If you choose to do this, use the Agent Weightingproperty to reduce the amount of load generated by the agent installed on the same computer as the controller.

It is recommended that you install the agents on their own computer. Anything that is processing at the same time the agent is running affects the accuracy of the test. Agent weighting reduces the impact, but inaccuracies are still introduced.

The following additional configurations are available. They are listed in order of recommendation.

 

Alternative Configuration 1

· Computer 1: Visual Studio, Controller, SQL Express

· Computer 2-n: Agents

Alternative Configuration 2

· Computer 1: Visual Studio

· Computer 2: Controller, Agent

· Computer 3: SQL Express

· Computer 4-n: Agents

Alternative Configuration 3

· Computer 1: Visual Studio

· Computer 2: Controller, SQL Express, Agent

· Computer 3-n: Agents

 

Performance Considerations

Here are some additional considerations to consider when sizing the hardware:

 

	Agent	Controller Application Tier	Controller Data Tier	Controller AT/DT
CPU	Depending on the test, the CPU is frequently the limiting factor	Not heavily used	Not heavily used	Not heavily used
Disk	Not heavily used	Not heavily used	10 GB space required for 24 hours of test data	10 GB space required for 24 hours of test data
Memory	Depending on the test, memory will be the limiting factor	Not heavily used	Heavily used by SQL	Heavily used by SQL

 

The amount of load that a specific load agent can generate varies widely from test to test. Most tests are bound by the CPU. CPU use is directly proportional to requests per second (RPS). For other load tests, memory is the limiting factor. The RPS you can expect to drive from a load agent depends upon many factors. These include the following:

· User load

· Think time

· Authentication scheme

· Size of requests and responses

· Response time

· Level of response validation

· Test Type under load (either Web Test or Unit Test)

Think time is the primary factor for determining the number of users on a CPU-bound test. Changing think times from 2 seconds to 10 seconds allows you simulate 5 times more users, but the RPS being generated will be the same. If your goal is to simulate real users, set the think time to a value that reflects how you believe users will behave on your Web site. Increasing think time and the number virtual users will not necessarily place additional stress on your Web application.

Agents can be bound by memory on tests that use the Connection Per User connection mode. Two connection modes can be configured in the load test run settings. In Connection Pool mode (the default), connections are pooled, but each user still uses two connections when active. In this mode, all virtual users are multiplexed over the connection pool. This allows you to have 1000 active virtual users sharing 100 connections. In Connection Per User mode, each user has a connection that consists of two actual connections open to the server.

If load testing against a typical ASP.NET application with 3 to 5 second think time using Web tests, you can simulate around 1000 users from a single-processor load test agent with a 2 GHz CPU and 1 GB RAM (recommended configuration). The number of users supported is a function of the think time. With longer think times, more users can be supported.

 

SQL Sizing Considerations

By default, SQL Express is installed on the controller and is used by the controller as the default SQL store for load test results. The SQL Express database is license-limited to store 10 GB of data, which is around 24 hours of load test data for a typical load test. The space that is required for load test data varies greatly depending on the test.

During a load test, samples are collected for each counter instance on each computer. Therefore, the amount of space that is required in the database depends on the following factors: the number of counters collected, the number of computers involved in the test, and the number of samples taken, as controlled by the sample rate.

If appropriate, consider using a separate database to store the load test data. The database can be stored on either the controller computer or on a different computer. To change the data store, submit the SQL commands contained in the .sql file to the SQL server instance you want to use for the load test results store. These are two ways to do this. One way is to use the command sqlcmd from a command prompt and specify the options needed to connect to the desired database. Use the –i option to specify the path to loadtestresultsrepository.sql. Another way is to use one of the GUI interfaces to SQL, such as query analyzer, and open the .sql file and submit the connects.

 

Test Rig Software Requirements

Setup installs the following required components:

 

Component	Requirements	Version
Controller	SQL Express	2005
	.NET Framework	2.0
Agent	.NET Framework	2.0

 

Test Rig User Accounts

The following types of accounts exist in the rig. Before installing, create the required accounts on the rig computers.

 

Account Name	Description	Requirements
Setup User	User who installs the controller and agent.	This user must be an Administrator on the computer they are running Setup on, and be an Administrator on the Controller.
Controller Service account	User the controller is running as. During Setup, you are prompted for this user account.	This user must have access to read performance counters from computers under test during a load test because the controller service collects performance counters during a load test. If running in Workgroup (non-domain), a local computer account that has the same user name and password must exist on all agents. To restart the rig, the Controller Service User is added to the Agent Administrators group during Agent Setup.
Agent Service account	User the agent service is running as. During Setup, you are prompted for this user name.	By default, tests are run as this user. (There is a way to run tests as a different user). Therefore, this user needs the access as required by the tests you are running. If you turn on Agent Logging, this user needs write access to the installation directory.

 

Requirements for Workgroups

If the computers in a rig are running in Work Group mode, that is, they are not in a domain, or they are running in different non-trusted domains, create local computer accounts on the controller. The accounts should have a matching password for each user who will access the controller, including the Agent service users.

For example, you have three computers, Controller1, Agent1, and Agent2. You must create local computer accounts on each computer for the agent service user and controller user. You also must make sure an administrator account exists on all three computers with the same username and password.

 

Computer Name	User Account	Password
Controller1	ControllerService	ControllerServicePassword
Agent1	ControllerService	ControllerServicePassword
Agent2	ControllerService	ControllerServicePassword
Controller1	AgentService	AgentServicePassword
Agent1	AgentService	AgentServicePassword
Agent2	AgentService	AgentServicePassword

 

Note: If you are running on Windows XP in a work group, you must turn off Simple File Sharing. See this KB for info on how to do that:http://support.microsoft.com/kb/307874

Open Windows Explorer, choose Tools, and then choose Folder Options, Next, select the View tab, and turn off the “Use Simple File Sharing (Recommended)” option.

Accessing the Controller

After the controller is installed, access to the controller is limited to members of the TeamTestControllerUsers and TeamTestControllerAdmins groups that were created during Setup, and to the Administrators group. Add appropriate users and/or groups to these groups to allow them to access the controller. Members of the TeamTestControllerAdmins group or the Administrators group can administer the controller by clicking the Test menu, and then choosingAdminister Test Controller in Visual Studio. Members of the TeamTestControllerAdmins group must also be power users or administrators on the controller computer.