Infrastructure for load testing in the cloud - with Visual Studio 2013 and only when necessary

This article was created with the invaluable help of our colleague from Kaspersky Lab, Igor Shcheglovitov , a QA engineer in the department of cloud technology research. Preface - by ahriman.

The biggest challenge in load testing is to start doing it. What you need to start doing load testing? In general, one machine and target service. This method is good exactly until the moment when the resources of one machine are no longer enough to generate the necessary load.

It ceased to be enough one car - we take two. Three. Ten. Where to get ten cars? Ask the IT department. After completing load testing, notify the IT department. Two hours after the IT department returns the infrastructure to its ownership, [something] is discovered and the infrastructure is needed again. We ask again - and the time that the IT department previously spent on infrastructure deployment has suddenly increased (of course, no one knows why).

The usual story. Developers want to quickly get and start using. Load testing is an iterative process, and infrastructure build-up is also. What if developers had this infrastructure all the time? Customized, on request? Turned off when not necessary to pay the very minimum? How to deploy this infrastructure based on Visual Studio 2013 - in the article. As a result, you will have always available ready-made infrastructure for load testing, which is enough to turn on - and you can start testing. In the off state, only the storage for the images of these machines will be paid.
')



Objective : To create an infrastructure for load testing.

Description :
The entire infrastructure will be deployed in Microsoft Azure virtual machines.
Load testing in Microsoft Azure can be performed in three versions:

1. Visual Studio Online (http://www.visualstudio.com/en-us/get-started/load-test-your-app-vs).
2. Microsoft Azure Cloud Services
3. Virtual machines

In complex cases, you may need to have all the infrastructure participating machines merged into a domain or located in a hybrid model with a VPN — we will omit this situation, since the article will then be somewhat larger.

Test object
WCF service that provides one synchronous method (calculator) for SOAP. The solution can be used to test projects of any complexity. The service can be hosted both as a Cloud Service and as an ordinary service on a separate virtual machine. If the service is hosted on a virtual machine, then during the load process we will be able to collect any necessary (configured) performance counters from the machine. However, there will be no automatic scaling capability that Cloud Service has. Our service will provide one endpoint for connection, by basicHttpBinding.

Sequencing:
In the process of laboratory work, 4 virtual machines will be deployed on Microsoft Azure:

• Test controller and SQL 2012 Express Server

• Testing agent

• Test service (SUT - System under the testing)

• Visual Studio 2013, which will be developed load test

Controller
Create a controller — while selecting an image on Microsoft Azure, select a Windows 2012 Server R2 image. In the virtual machine settings during creation, open the following ports:
a) TCP port 445 for remote assembling performance counters
b) UDP port 1434 for SQL Browser and TCP 1433 for connection to SQL server
c) TCP port to connect to Test Controller`y 6901
d) Remote Destop, it is needed on all created virtual machines.



Connect to the virtual machine via RDP (by clicking the Connect / Connect button in the Microsoft Azure management portal) and download Agents for Microsoft Visual Studio 2013 . Install TestController (vstf_testcontroller.exe)

After installation, run the Test Controller Configuration Tools and specify the account with which you connect to the virtual machine. Check the box Configure test controller for load testing .



Download and install the SQL Server Express distribution using the UI link. Launch SQL Server Configuration Manager and enable Pipe and TCP / IP protocols. In the TCP / IP settings, enable all available IP addresses Enabled and for IPAll set the static port 1433.



On the SQL Server Services tab, enable and start the SQL Server Browser and SQL Server services.

In the Firewall settings, allow connections to the following ports:
a) outgoing connections to the agent (port 6910)
b) incoming connections to the 6901 controller service
c) incoming connections to the RPC service to collect performance counters - port 445
d) connection to the studio (LoadTest framework), outgoing port 6915
e) incoming connections on TCP port 1433 and UDP 1434

For simplicity, you can write and execute the bat file:

netsh advfirewall firewall add rule name = "Test Agent Out" dir = out action = allow protocol = TCP localport = 6910
netsh advfirewall firewall add rule name = "Test Controller In" dir = in action = allow protocol = TCP localport = 6901
netsh advfirewall firewall add rule name = "RPC In" dir = in action = allow protocol = TCP localport = 445
netsh advfirewall firewall add rule name = "VS Studio Out" dir = out action = allow protocol = TCP localport = 6915
netsh advfirewall firewall add rule name = "SQL Express" dir = in action = allow protocol = TCP localport = 1433
netsh advfirewall firewall add rule name = "SQL Browser" dir = in action = allow protocol = UDP localport = 1434

Open the HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa registry key and add the DisableLoopBackCheck (value 1) parameter to the DWODR. This solves the problem of connecting to a SQL server from an external domain. In order for the testing agent to be able to connect to the controller, you need to set the DNS suffix in the IPv4 (network adapter) settings:



Go to Test Controller Configuration Tools. In the line for connecting to the SQL database, register instead of localhost the full DNS name of the virtual machine and click Apply settings.



The test controller configuration process begins. The last message will be a warning, which is not worth paying attention to.
Agent
Create a new virtual machine. When creating, open the following ports:
a) TCP port 445 for remote build performance counters
c) TCP port to connect to Test Agent `y 6910
d) TCP port Remote Desktop

Connect to the created machine via RDP (by clicking the Connect button) and download the distribution <a href=" "> Test Agent . Install the Test agent.

In the Firewall settings, you should allow connections to the following ports:
a) Incoming connections to the 6910 controller service.
b) Outgoing connections to test controller 6901
c) Inbound connections to the RPC service to collect performance counters - port 445
d) Outgoing TCP connections to the port that is listening to the test service, in our case this is 9117.

bat file:
netsh advfirewall firewall add rule name = "Test Agent In" dir = in action = allow protocol = TCP localport = 6910
netsh advfirewall firewall add rule name = "Test Controller Out" dir = out action = allow protocol = TCP localport = 6901
netsh advfirewall firewall add rule name = "RPC In" dir = in action = allow protocol = TCP localport = 445
netsh advfirewall firewall add rule name = "Test service OUT" dir = out action = allow protocol = TCP localport = 9117

Write in the DNS settings of the network adapter the suffix cloudapp.net.
Run the Configuration Test Agent, (you will be prompted that the agent can be launched as a service or a dextop application, select the service). Enter your account.

Register the connection line to the testing controller (DNS + port) and click Apply.
If during configuration, the Test Agent gives an error that the controller cannot communicate with the agent, but the log shows that the agent was able to connect to the controller, then in the controller configuration (on the corresponding machine), in the appsettings section, specify the setting:
/>
( details )
At this step, the connection between the agent and the controller should be established.

Virtual machine with a test service

The WCF service was chosen as the test object.
Interface:
[ServiceContract]
public interface iCalculator
{
[OperationContract]
int Sum (int a, int b, int timeOutInMiliseconds);
}

The source code together with the executable binary files can be taken here (project CalculatorService). Create a new virtual machine. When creating, open the ports:
9117. This port listens on our test service.
RPC port 445.

After creation, open the same ports in the operating system's firewall.

Next, use the sc create NewService command binpath = ".... \ Debug \ CalculatorService.exe to create and run a test service from the services snap-in (services.msc).

Studio

Create a new virtual machine (Windows 8, with Visual Studio 2013 Ultimate). In the console, open port 6915. This port is needed by the test controller to interact with the studio.

Connect to the virtual machine via RDP.
In the Firewall settings:
a) Open port 6915 for incoming connections
b) Open port 6901 for outgoing to controller
c) Outgoing ports UDP 1434 and TCP 1433 for connection to SQL database
d) Outbound 445 to connect to RPC (performance counters collection)

Also, as elsewhere, list the DNS suffix cloudapp.net in the IPv4 settings.
After that, you should gain access for remote collection of performance counters.

To do this, run the command:
net use \\ machineName \ IPC $ { password } / user : { username } / persistent : yes

As a machineName, you can list all the virtual machines - the controller, the agent, the machine with the test service installed.

Start Visual Studio 2013. Open Solution from the solution package. Create a new Web performance And Load Test Project. Add UnitTestProject1 into it (it contains a simple test method along with a wrapper for calling the Calculator test service)
In SolutionItems, add a new file of type TestSettings and open it. On the Roles tab, install RemoteExecution and manually register the DNS name of the controller virtual machine.



In the Load Test menu, select the Manage Test Controller tab and make sure that the studio can connect to the controller:



The line of connection to the database and the name of the agent (if it is active) should be visible.
From the Load Test menu, select Select active test settings => Remote.testsettings. Create a new LoadTest. In the Load Test Wizard, on the Test Mix tab, add a TestMethod1 unit test from the UnitTestProject project. If it is not displayed, then close the Wizard and recompile the solution.
On the Counter Set tab, add the machine on which the test service is installed (if we want to collect counters from it during the test) and select at least one of the default sets of counters for it.



Save the test. Add WCF performance counters from the machine with the test service.
To do this, double click on the created load test. Using the right mouse button to create a new Counter Set. Right-click on the created Counter Set and select Add counters. Select the desired computer (from which you need to read the available counters) and the desired counter.



Click OK, after which you can add the created Counter Set to Counter Set Mapping so that the system collects the counters during the test.

Now the test can be run. The test results of each test run will be saved to the LoadTest database automatically created on the controller.

Using MS Office plug-ins, you can build a very detailed report on load testing (see http://msdn.microsoft.com/en-us/library/ee923686.aspx for more details) - compare two launches of any relative counters (response time, errors, memory , processor time, etc.) or build the dynamics of change of each counter in the range of test runs.
Testing agents can be scaled horizontally. Those. Using the Microsoft Azure Management Console, you can save an image of a virtual machine with a testing agent and create its clone. After starting it will automatically connect to the controller.
Thanks to this approach, the load can be generated from several agents at once. This is necessary when one agent fails.