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

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

Перестало хватать одной машины – берем две. Три. Десять. Стопицот. Где взять столько машин? Попросить у IT-отдела. Закончив нагрузочное тестирование, уведомить об этом IT-отдел. Через два часа после того, как IT-отдел вернет инфраструктуру в свое владение, ВНЕЗАПНО обнаруживается НЕЧТО и инфраструктура нужна снова. Просим опять – и время, которое IT-отдел потратил ранее на развертывание инфраструктуры, внезапно увеличилось (конечно, непонятно почему).

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

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

Описание:

Вся инфраструктура будет развертываться в виртуальных машинах 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. В настройках виртуальной машины при создании откройте следующие порты:
a) TCP порт 445 для удаленного сборка счетчков производительности
b) UDP порт  1434  для SQL Browser и TCP 1433 для подключения к SQL серверу
c) TCP порт для подключения к Test Controller`y 6901
d) 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 адреса Enabled и для IPAll установите статический порт 1433.

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

В настройках Firewall`a разрешите подключения на следующие порты:
a) исходящие подключения на агент (порт 6910)
b) входящие подключения к службе контроллера 6901
c) входящие подключения к службе RPC для сбора счетчиков производительности – порт 445
d) подключения к студии (фреймворку LoadTest), исходящий порт 6915
e) входящие подключения на 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.

Начнется процесс конфигурирования контроллера тестирования. В последнем сообщении будет warning, на который не стоит обращать внимания.
Агент
Создайте новую виртуальную машину. При создании откройте следующие порты:
a) TCP порт 445 для удаленного сборка счетчиков производительности
c) TCP порт для подключения к Test Agent`y 6910
d) TCP порт Remote Desktop

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

В настройках Firewall`a следует разрешить подключения на следующие порты:
a) Входящие подключения к службе контроллера 6910.
b) Исходящие подключения к контроллеру тестирования 6901
c) Входящие подключения к службе RPC для сбора счетчиков производительности – порт 445
d) Исходящее 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. Данный порт прослушивает наш тестовый сервис.
RPC порт 445.

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

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

Студия

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

Подключитесь к виртуальной машине по RDP.
В настройках Firewall:
a) Откройте порт 6915 для входящих соединений
b) Откройте порт 6901 для исходящих на контроллер
c) Исходящие порты UDP 1434 и TCP 1433 для подключения к базе SQL
d) Исходящий 445 для подключения к RPC (сбор cчетчиков производительности)

Также, как и везде, пропишите DNS суффикс cloudapp.net в настройках IPv4.
После этого следует получить доступ для удаленного сбора счетчиков производительности.

Для этого выполните команду:
net use \\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, можно сохранить образ виртуальной машины с агентом тестирования и создать его клон. После запуска он автоматически подключится к контроллеру.
Благодаря этому подходу нагрузку можно генерировать сразу с нескольких агентов. Это нужно, когда один агент не справляется.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *