Инфраструктура для нагрузочного тестирования в облаке — с Visual Studio 2013 и только тогда, когда надо

Самое сложное в нагрузочном тестировании — начать его делать. Что нужно, чтобы приступить к нагрузочному тестированию? В общем случае – одна машина и целевой сервис. Этот метод хорош ровно до того момента, покуда ресурсов одной машины перестанет хватать для генерации нужной нагрузки.

Перестало хватать одной машины – берем две. Три. Десять. Где взять десять машин? Попросить у ИТ-отдела. Закончив нагрузочное тестирование, уведомить об этом ИТ-отдел. Через два часа после того, как ИТ-отдел вернет инфраструктуру в свое владение, обнаруживается [нечто] и инфраструктура нужна снова. Просим опять – и время, которое ИТ-отдел потратил ранее на развертывание инфраструктуры, внезапно увеличилось (конечно, никто не знает, почему).

Обычная история. Разработчики хотят быстро получить и начать использовать. Нагрузочное тестирование – это процесс итеративный, и наращивание инфраструктуры – тоже. Что, если бы разработчики имели эту инфраструктуру постоянно? Настроенную, по запросу? Выключенную, когда не надо, чтобы платить самый минимум? О том, как развернуть эту инфраструктуру на основе Visual Studio 2013 пойдет речь в данной статье. В результате у вас будет всегда доступная готовая инфраструктура для нагрузочного тестирования, которую достаточно включить — и можно приступать к тестированию. В выключенном состоянии оплачиваться будет только хранилище для образов этих машинh

Увеличить

Цель: Создать инфраструктуру для нагрузочного тестирования.

Описание:
Вся инфраструктура будет развертываться в виртуальных машинах Microsoft Azure. Нагрузочное тестирование в Microsoft Azure может быть выполнено в трех вариантах:

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

В сложных случаях вам может понадобиться, чтобы все машины-участники инфраструктуры были объединены в домен или располагались в гибридной модели с VPN – мы опустим эту ситуацию, так как статья будет в таком случае несколько больше.

Объект тестирования

Сервис WCF, который предоставляет по SOAP один синхронный метод (калькулятор). Решение можно использовать для тестирования проектов любой сложности. Размещаться сервис может и как Cloud Service, и как обычный сервис на отдельной виртуальной машине. Если сервис будет размещаться на виртуальной машине, то в процессе нагрузки мы сможем собирать с машины любые нужные (настроенные) счетчики производительности. Однако будет отсутствовать возможность автоматического масштабирования, которая есть у Cloud Service. Наш сервис будет предоставлять одну конечную точку для подключения, по basicHttpBinding.

Последовательность действий:

В процессе лабораторной работы будет развернуто 4 виртуальные машины на Microsoft Azure:

• Контроллер тестирования и SQL 2012 Express Server
• Агент тестирования
• Тестовый сервис (SUT – System under the testing)
• Visual Studio 2013, в которой будет разработан нагрузочный тест

Контроллер

Создайте контроллер — во время выбора образа на Microsoft Azure выберите образ Windows 2012 Server R2. В настройках виртуальной машины при создании откройте следующие порты:

• TCP порт 445 для удаленного сборка счетчков производительности
• UDP порт  1434  для SQL Browser и TCP 1433 для подключения к SQL серверу
• TCP порт 6901 для подключения к Test Controller`y
• Remote Destop, он нужен на всех создаваемых виртуальных машинах.

Увеличить

Подключитесь к виртуальной машине через RDP (нажав на кнопку Connect/Подключение на портале управления Microsoft Azure) и загрузите Agents для Microsoft Visual Studio 2013. Установите TestController (vstf_testcontroller.exe)

После установки запустите Test Controller Configuration Tools и укажите аккаунт, с которым подключаетесь к виртуальной машине. Отметьте галочку Configure test controller for load testing.

Загрузите и установите дистрибутив SQL Server Express по ссылке на UI. Запустите SQL Server Configuration Manager и включите Pipe и TCP/IP-протоколы. В настройках TCP/IP включите все доступные IP-адреса и для IPAll установите статический порт 1433.


Увеличить

На вкладке SQL Server Services включите и запустите службы SQL Server Browser и SQL Server.

В настройках Firewall`a разрешите подключения на следующие порты:

• исходящие подключения на агент (порт 6910)
• входящие подключения к службе контроллера 6901
• входящие подключения к службе RPC для сбора счетчиков производительности – порт 445
• подключения к студии (фреймворку LoadTest), исходящий порт 6915
• входящие подключения на TCP порт 1433 и UDP 1434

Для простоты можно написать и выполнить bat-файл:

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

Откройте ветку реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa и добавьте туда DWODR параметр DisableLoopBackCheck (значение 1). Это решает проблему с подключением к SQL cерверу из внешнего домена. Чтобы агент тестирования смог подключиться к контроллеру, надо в настройках IPv4 (сетевого адаптера) прописать DNS-суффикс:


Увеличить

Перейдите в Test Controller Configuration Tools. В строчке подключения к SQL-базе пропишите вместо localhost полное DNS-имя виртуальной машины и нажмите Apply settings.


Увеличить

Начнется процесс конфигурирования контроллера тестирования. В последнем сообщении будет предупреждение, на которое не стоит обращать внимания.

Агент

Создайте новую виртуальную машину. При создании откройте следующие порты:

• TCP-порт 445 для удаленного сборка счетчиков производительности
• TCP-порт 6910для подключения к Test Agent`y
• TCP-порт Remote Desktop

Подключитесь к созданной машине по RDP (нажав кнопку Connect/Подключение) и загрузите дистрибутив Test Agent. Установите Test agent.

В настройках Firewall`a следует разрешить подключения на следующие порты:

• входящие подключения к службе контроллера 6910,
• исходящие подключения к контроллеру тестирования 6901,
• входящие подключения к службе RPC для сбора счетчиков производительности – порт 445,
• исходящее TCP-подключения на порт, который прослушивает тестовый сервис, в нашем случае это 9117.

bat–файл:
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

Пропишите в настройках DNS сетевого адаптера суффикс cloudapp.net.

Запустите Configuration Test Agent (появится предложение, что агент может быть запущен как сервис или декстопное приложение, выберите сервис). Укажите свой аккаунт.

Пропишите строчку подключения к контроллеру тестирования(DNS + порт) и нажмите Apply.

Если во время конфигурирования Test Agent выдаст ошибку, что не удается установить связь контроллера с агентом, но по журналу будет видно, что агент смог подключиться до контроллера, то в этом случае в конфигурации контроллера (на соответствующей машине) в разделе appsettings следует прописать настройку:
/>

( подробности)

На этом шаге должна быть установлена связь между агентом и контроллером.

Виртуальная машина с тестовым сервисом

В качестве объекта тестирования была выбрана WCF-служба.
Интерфейс:
[ServiceContract]
public interface ICalculator
{
[OperationContract]
int Sum(int a, int b, int timeOutInMiliseconds);
}

Исходный код вместе с исполняемыми бинарными файлами можно взять здесь (проект CalculatorService). Создайте новую виртуальную машину. При создании откройте порты:

9117 (данный порт прослушивает наш тестовый сервис)

445 (RPC порт).

После создания откройте эти же порты в Firewall операционной системы.

Далее, с помощью команды sc create NewService binpath="....\Debug\CalculatorService.exeсоздайте и запустите тестовый сервис из оснастки сервисов (services.msc).

Студия

Создайте новую виртуальную машину (Windows 8, с Visual Studio 2013 Ultimate). В консоли откройте порт 6915. Данный порт нужен контроллеру тестирования для взаимодействия со студией.

Подключитесь к виртуальной машине по RDP.

В настройках Firewall:

• откройте порт 6915 для входящих соединений,
• откройте порт 6901 для исходящих на контроллер,
• исходящие порты UDP 1434 и TCP 1433 для подключения к базе SQL,
• исходящий 445 для подключения к RPC (сбор cчетчиков производительности).

Так же, как и везде, пропишите DNS-суффикс cloudapp.net в настройках IPv4.

После этого следует получить доступ для удаленного сбора счетчиков производительности.

Для этого выполните команду:
netuse \\machineName\IPC${password} /user:{username} /persistent:yes

В качестве machineName можно перечислить все виртуальные машины: контроллер, агент, машина с установленным тестовым сервисом.

Запустите Visual Studio 2013. Откройте Solution из пакета с решением. Создайте новое решение Web performance And Load Test Project. Добавьте в него UnitTestProject1 (в нем содержится простой тестовый метод вместе с оберткой для вызова тестового сервиса Calculator)
В SolutionItems добавьте новый файл типа TestSettings и откройте его. На вкладке Roles установите RemoteExecution и пропишите вручную DNS-имя виртуальной машины контроллера.


Увеличить

В меню Load Test выберите вкладку Manage Test Controller и убедитесь, что студия может подключиться к контроллеру:


Увеличить

Должны быть видны строчка подключения к базе и наименование агента (если он активен).

В меню Load Test выберите Select active test settings => Remote.testsettings. Создайте новый LoadTest. В Load Test Wizard на вкладке Test Mix добавьте юнит-тест TestMethod1 из проекта UnitTestProject. Если он не отображается, то надо закрыть Wizard и перекомпилировать решение.

На вкладке Counter Set добавьте машину, на которой установлен тестовый сервис (если мы хотим в процессе тестирования собираться с него счетчики), и выбрать для нее хотя бы один из доступных по умолчанию наборов счетчиков.


Увеличить

Сохраните тест. Добавьте WCF-счетчики производительности для машины с тестовым сервисом.

Для этого надо два раза кликнуть на созданный нагрузочный тест. Используя правую кнопку мыши, создать новый Counter Set. Нажать правой кнопкой мыши на созданный Counter Set и выбрать Add counters. Выбрать нужный компьютер (с которого надо прочитать доступные счетчики) и нужный счетчик.


Увеличить

Нажать OK, после чего можно добавить созданный Counter Set в Counter Set Mapping, чтобы система собирала счетчики в процессе прохождения теста.

Теперь тест можно запустить. Результаты тестирования каждого прогона теста будут сохраняться в автоматически созданную на контроллере базу LoadTest.

Используя плагины MS Office, можно построить очень подробный отчет по нагрузочному тестирования (подробнее на http://msdn.microsoft.com/en-us/library/ee923686.aspx) – сравнить два запуска относительного любого счетчики (время отклика, ошибки, память, процессорное время и т.п.), либо построить динамику изменения каждого счетчика по диапазону прогонов теста.
Агенты тестирования можно масштабировать горизонтально. Т.е. используя консоль управления Microsoft Azure, можно сохранить образ виртуальной машины с агентом тестирования и создать его клон. После запуска он автоматически подключится к контроллеру.

Благодаря этому подходу нагрузку можно генерировать сразу с нескольких агентов. Это нужно, когда один агент не справляется.

Эта статья была создана с неоценимой помощью нашего коллеги из Лаборатории Касперского, Игоря Щегловитова, инженера QA отдела исследований облачных технологий. Предисловие – от ahriman.