Эта статья была создана с неоценимой помощью нашего коллеги из Лаборатории Касперского, Игоря Щегловитова, инженера QA отдела исследований облачных технологий. Предисловие – от ahriman.
Самая сложность в нагрузочном тестировании — начать его делать. Что нужно, чтобы начать делать нагрузочное тестирование? В общем случае – одна машина и целевой сервис. Этот метод хорош ровно до того момента, как ресурсов одной машины перестанет хватать для генерации нужной нагрузки.
Перестало хватать одной машины – берем две. Три. Десять. Где взять десять машин? Попросить у IT-отдела. Закончив нагрузочное тестирование, уведомить об этом IT-отдел. Через два часа после того, как IT-отдел вернет инфраструктуру в свое владение, обнаруживается [нечто] и инфраструктура нужна снова. Просим опять – и время, которое IT-отдел потратил ранее на развертывание инфраструктуры, внезапно увеличилось (конечно, никто не знает, почему).
Обычная история. Разработчики хотят быстро получить и начать использовать. Нагрузочное тестирование – это процесс итеративный, и наращивание инфраструктуры – тоже. Что, если бы разработчики имели эту инфраструктуру постоянно? Настроенную, по запросу? Выключенную, когда не надо, чтобы платить самый минимум? О том, как развернуть эту инфраструктуру на основе Visual Studio 2013 – в статье. В результате у вас будет всегда доступная готовая инфраструктура для нагрузочного тестирования, которую достаточно включить — и можно приступать к тестированию. В выключенном состоянии оплачиваться будет только хранилище для образов этих машин.
Цель: Создать инфраструктуру для нагрузочного тестирования.
Описание:
Вся инфраструктура будет развертываться в виртуальных машинах Microsoft Azure.
Нагрузочное тестирование в Microsoft Azure может быть выполнено в трех вариантах:
- Visual Studio Online (http://www.visualstudio.com/en-us/get-started/load-test-your-app-vs).
- Microsoft Azure Cloud Services
- Virtual Machines
Объект тестирования
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, можно сохранить образ виртуальной машины с агентом тестирования и создать его клон. После запуска он автоматически подключится к контроллеру.
Благодаря этому подходу нагрузку можно генерировать сразу с нескольких агентов. Это нужно, когда один агент не справляется.
