Экспорт (0) Печать
Развернуть все

Запуск нагрузочных тестов в смешанных средах

В этом разделе описывается выполнение нагрузочных тестов Visual Studio в смешанной среде. «Смешанная среда» — это среда, где компоненты нагрузочного теста размещаются в разных контекстах, например локально или как рабочие роли Windows Azure. Например, смешанной средой будет среда, где тестовые агенты работают локально, а репозиторий данных размещен на сервере База данных SQL Windows Azure. Такая конфигурация отличается от системы, описанной в разделе Общие сведения о нагрузочном тесте Visual Studio в Windows Azure. В этом разделе все компоненты, за исключением рабочей станции, выполняются как рабочие роли Windows Azure.

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

Авторы: Джейми Альва Браво (Jaimie Alva Bravo), Сидни Хига (Sidney Higa), Паоло Сальватори (Paolo Salvatori).

Загрузка

Файлы, необходимые для выполнения этих процедур, находятся здесь: VSLoadTestInMixedEnvironments

Параллелизм

Одним из факторов, используемых при сравнении различных конфигураций, является увеличение параллелизма за счет запуска многих процессов в крупном центре обработки данных. Параллелизм определяется как свойство системы выполнять несколько задач одновременно и, возможно, взаимосвязанно. Ограничивает параллелизм количеством доступных IP-адресов. Чем больше IP-адресов использует система, тем больше параллелизм при обработке. Как правило, количество адресов зависит от величины вашего поставщика IP-адресов. Если ваше соглашение об уровне обслуживания достаточно масштабное, то для него обычно выделяется большое количество IP-адресов. Однако такие соглашения не слишком распространены. Однако, когда вы применяете Windows Azure в качестве платформы, вы можете использовать центр обработки данных Майкрософт и его ресурсы. В число этих ресурсов входит и большой пул IP-адресов. Размещенным службам Windows Azure назначаются виртуальные IP-адреса. В данном контексте IP-адреса используются средством подсистемы балансировки загрузки, направленным во внешние системы (Интернет), а не размещенными службами. А наличие большого числа адресов является преимуществом центра обработки данных Майкрософт. Учтите также, что не всем системам требуется такой уровень параллелизма.

Улучшенные возможности для параллельной обработки — это еще одно большое преимущество выполнения нагрузочных тестов в Window Azure. Такой уровень параллелизма сложно воспроизвести вне крупного центра обработки данных.

Факторы

Существует шесть факторов, которые влияют на параллелизм. Первые два фактора — это контексты, в которых выполняется нагрузочный тест: облако и локальная система.

  • Локальная система

  • Облако

Другие четыре фактора — это компоненты нагрузочного теста. Они перечислены ниже:

  • тестовый контроллер,

  • тестовые агенты,

  • репозиторий результатов,

  • тестируемая система

Эти четыре компонента показаны далее.

Факторы тестирования нагрузки

На рисунке относительная ширина линий представляет объем передаваемых данных. Чем толще линия, тем больше данных. Наиболее интенсивная передача данных происходит между тестовым контроллером и репозиторием результатов. Наименьшая нагрузка — между тестируемой системой и контроллером. (Однако фактическая нагрузка зависит от объема данных журналов, созданных тестируемыми системами.) Для справки см. рисунок в разделе Общие сведения о нагрузочном тесте Visual Studio в Windows Azure.

noteПримечание
Ради ясности на рисунке предполагается, что рабочая станция, на которой размещена среда Visual Studio, также содержит тестовый контроллер. Эта конфигурация облегчает взаимодействие между Visual Studio и тестовым контроллером. Во время нагрузочного теста контроллер передает объемные потоки данных в Visual Studio для наблюдения за производительностью в реальном времени.

Топологии

С учетом четырех компонентов и двух контекстов очевидны различные варианты топологии. Четыре компонента нагрузочного теста могут существовать в одном или другом контексте. Например, далее приведены две простейшие топологии.

  1. Все компоненты находятся в облаке.

  2. Все компоненты расположены в локальной системе.

Ради ясности в этой таблице показаны два простейших варианта.

 

Контроллер Агенты Репозиторий Тестируемая система Примечания

Локальная система

Локальная система

Локальная система

Локальная система

Ограниченный параллелизм, нет сетевого трафика вне локальной системы.

Облако

Облако

Облако

Облако

Улучшенный параллелизм (больше IP-адресов), и нет сетевого трафика за пределами облака.

А теперь более сложные топологии. Для простоты в этой таблице показано одно крупное деление. В этой таблице контроллер работает локально.

Трафик от агентов к тестируемой системе не учитывается, так как предполагается, что он входит в стоимость каждого теста. Обратите внимание на денежное выражение стоимости сетевого трафика в следующих таблицах. С вас будет взиматься плата за данные, переданные за пределы центра обработки данных. Внутренний трафик не тарифицируется. Сведения о ценообразовании см. в статье Подробности ценообразования (выполните поиск «передача данных, измеряемых в ГБ»).

В следующей таблице показана крупная точка разделения: когда тестовый контроллер работает локально. В этом случае трафик между компонентами должен пересекать границу с различными последствиями в зависимости от компонента и того, насколько он «разговорчивый».

Контроллер работает локально

Контроллер Агенты Репозиторий Тестируемая система Примечания

Локальная система

Локальная система

Локальная система

Облако

Ограниченный параллелизм, есть сетевой трафик от тестируемой системы к контроллеру.

Локальная система

Локальная система

Облако

Локальная система

Ограниченный параллелизм, есть сетевой трафик от контроллера к репозиторию.

Локальная система

Локальная система

Облако

Облако

Ограниченный параллелизм, есть сетевой трафик от тестируемой системы к контроллеру и назад к репозиторию.

Локальная система

Облако

Локальная система

Локальная система

Улучшенный параллелизм, есть сетевой трафик от агентов к контроллеру.

Локальная система

Облако

Локальная система

Облако

Улучшенный параллелизм, есть сетевой трафик от агентов и тестируемой системы к контроллеру.

Локальная система

Облако

Облако

Локальная система

Улучшенный параллелизм, есть сетевой трафик от агентов к контроллеру и назад к репозиторию.

Локальная система

Облако

Облако

Облако

Улучшенный параллелизм, есть сетевой трафик от агента и тестируемой системы к контроллеру и назад к репозиторию.

В этой таблице показано второе крупное деление. В данной таблице контроллер работает в облаке.

Контроллер работает в облаке

Контроллер Агенты Репозиторий Тестируемая система Примечания

Облако

Локальная система

Локальная система

Локальная система

Ограниченный параллелизм, есть сетевой трафик от агента и тестируемой системы к контроллеру и назад к репозиторию.

Облако

Локальная система

Локальная система

Облако

Ограниченный параллелизм, есть сетевой трафик от агента к контроллеру и назад к репозиторию.

Облако

Локальная система

Облако

Локальная система

Ограниченный параллелизм, есть сетевой трафик от агента и тестируемой системы к контроллеру.

Облако

Облако

Облако

Облако

Улучшенный параллелизм, есть сетевой трафик от агентов к контроллеру.

Облако

Облако

Локальная система

Локальная система

Улучшенный параллелизм, есть сетевой трафик от тестируемой системы к контроллеру и назад к репозиторию.

Облако

Облако

Локальная система

Облако

Улучшенный параллелизм, есть сетевой трафик от контроллера к репозиторию.

Облако

Облако

Облако

Локальная система

Улучшенный параллелизм, есть сетевой трафик от тестируемой системы к контроллеру.

Облако

Несколько компонентов в облаке

Облако

Облако

Самая высокая степень параллелизма, по крайней мере от тестируемой системы в DC1 до контроллера в DC2 (возможно, больше в зависимости от настройки).

Рекомендации

Топологии показаны ради полноты представления. Вы могли бы выбрать другую топологию. Например, если для данных SQL Server требуется хранилище более 100 ГБ, то оно должно быть размещено локально. В настоящее время База данных SQL предоставляет хранилища размером не больше 100 ГБ. Но если у вас есть определенные возможности для маневра, вот лучшие топологии. Эти рекомендации наиболее эффективны и позволяют добиться наивысшей степени параллелизма в двух основных конфигурациях (контроллер размещен локально и в облаке).

Лучше, когда контроллер работает локально

Контроллер Агенты Репозиторий Тестируемая система Примечания

Локальная система

Облако

Локальная система

Локальная система

Улучшенный параллелизм, есть сетевой трафик от агентов к контроллеру.

Локальная система

Облако

Локальная система

Облако

Улучшенный параллелизм, есть сетевой трафик от агентов и тестируемой системы к контроллеру.

Лучше, когда контроллер работает в облаке

Контроллер Агенты Репозиторий Тестируемая система Примечания

Облако

Локальная система

Облако

Локальная система

Ограниченный параллелизм, есть сетевой трафик от агента и тестируемой системы к контроллеру.

Облако

Облако

Облако

Облако

Улучшенный параллелизм, есть сетевой трафик от агентов к контроллеру.

Облако

Несколько компонентов в облаке

Облако

Облако

Самая высокая степень параллелизма, по крайней мере от тестируемой системы в DC1 до контроллера в DC2 (возможно, больше в зависимости от настройки)

Требования при увеличении сложности

В реальном мире фактическая конфигурация компонентов может быть более сложной. Тестируемая система может содержать множество компонентов, каждый из которых действует как рабочая или веб-роль или использует локальные службы. Например, компонент инициализирует систему или предоставляет службы проверки. Вполне вероятно, что в этом случае многие компоненты должны взаимодействовать с другими частями системы. Этот набор компонентов является дополнением к самой системе нагрузочных тестов (состоящей из контроллера, агентов и репозитория). На следующем рисунке показана система, состоящая из множества частей. Рисунок предназначен только для демонстрации того, что реальное решение может состоять из многих компонентов с разнообразными требования к связи. Не ставилась цель подробно описать систему.

Пример комплексной конфигурации

С такой степенью сложности все еще возможно разместить различные компоненты в Windows Azure или локально, как это необходимо. В следующем разделе описываются шаги, которые требуется выполнить.

Настройка

В данном случае настройка — это набор альтернативных методов для основных процедур настройки, описанных в этом документе: Провизионирование Windows Azure для нагрузочного теста. Данные процедуры также описывают настройку портала управления с использованием нужных компонентов. Например, здесь описывается, как настроить учетную запись хранилища и создать группу Windows Azure Connect.

Первый вариант позволяет использовать База данных SQL в качестве репозитория результатов. Второй вариант показывает, как настроить конечные точки в каждой рабочей роли. Конечные точки позволяют осуществлять взаимодействие между агентами, тестируемыми системами, тестовым контроллером и (при необходимости) дополнительным фактором — рабочей станцией, на которой размещена среда Visual Studio. В самом простом режиме компьютер размещен локально. Но если ваше приложение требует использовать его во время выполнения теста, он также может размещаться как рабочая роль Windows Azure.

Предварительные требования

Выполните следующие действия.

  • Загрузите файл LoadTest2010.bacpac.

  • Необязательно. Установите Visual Studio 2010 Ultimate на рабочей роли.

    Если вы собираетесь запустить тестовый контроллер в рабочей роли, установите в ней Visual Studio 2010 Ultimate. Добавьте рабочую роль в проект Windows Azure в Visual Studio. Убедитесь, что включен удаленный рабочий стол. Добавьте рабочую роль в группу Connect, чтобы подключить ее к вашему локальному сайту. С помощью удаленного рабочего стола подключитесь к рабочей роли и установите Visual Studio 2010 Ultimate.

Использование SQL BACPAC для подготовки базы данных SQL Windows Azure

Этот метод используется для сохранения результатов тестирования нагрузки в базе данных База данных SQL. Передайте файл с именем LoadTest2010.bacpac в вашу учетную запись хранилища Azure. Также необходимы следующие элементы:

  1. Учетная запись База данных SQL.

  2. Экземпляр SQL Server, созданный в подписке. Дополнительные сведения см. в разделе Создание сервера базы данных SQL Windows Azure.

  3. Имя пользователя и пароль с разрешением на изменение экземпляра сервера.

Провизионирование базы данных SQL с помощью BACPAC

  1. Передайте файл LoadTest2010.bacpac в вашу учетную запись хранилища Azure.

    Используйте StorageServicesSmartClient для передачи файла в открытый контейнер. После загрузки DACPAC-файла вы можете создать базу данных с помощью функции импорта портала управления.

  2. На портале управления щелкните База данных.

  3. Разверните подписку, содержащую сервер База данных SQL, который вы используете, и выберите сервер.

  4. В разделе База данных на ленте щелкните Импорт.

  5. Следуйте приведенным далее инструкциям для импорта файла LoadTest2010.bacpac. Как импортировать приложение уровня данных (база данных SQL Windows Azure).

После создания репозитория в База данных SQL настройте тестовый контроллер. В частности, задайте строку подключения для хранилища результатов. Диалоговое окно для установки значения доступно только в Visual Studio Ultimate. Однако перед продолжением вы должны сделать выбор. Решите, будет ли работать тестовый контроллер:

  1. На локальном компьютере.

    Если выбран этот параметр (на локальном компьютере), следуйте представленным далее инструкциям.

  2. В рабочей роли в Windows Azure, на которой работает экземпляр Visual Studio.

    Если вы решили запустить тестовый контроллер из рабочей роли в Windows Azure:

    1. Создайте группу Windows Azure Connect.

    2. Добавьте в группу локальную рабочую станцию.

    3. Развернув размещенную службу, подключитесь с помощью удаленного рабочего стола к рабочей роли, в которой будет размещаться Visual Studio.

    4. Установите Visual Studio 2010 Ultimate из файла установки (MSI) в вашей сети

Настройка локального экземпляра тестового контроллера

  1. Запустите Visual Studio от имени администратора.

  2. В Visual Studio в меню Тест щелкните Управление тестовыми контроллерами.

  3. Под текстом Загрузить хранилище результатов теста нажмите кнопку с многоточием.

  4. В диалоговом окне Свойства соединения вставьте имя сервера База данных SQL.

  5. Под текстом Входа на сервер выберите параметр Использовать проверку подлинности SQL Server.

  6. Параметру Имя пользователя задайте имя входа имя администратора База данных SQL.

  7. Введите в поле Пароль пароль администратора База данных SQL.

  8. В разделе Подключение к базе данных выберите базу данных LoadTest2010.

    Если строка подключения и учетные данные указаны правильно, изучите диалоговое окно Настройка тестового контроллера. Диалоговое окно содержит правильные значения.

Использование конечных точек вместо группы Azure Connect

Существует альтернатива использованию группы Connect: настройка конечных точек в каждой рабочей роли для обеспечения связи между экземплярами. У этого подхода есть определенное преимущество — более надежное соединение. Для реализации этого подхода выполните следующие действия.

Настройка конечных точек в экземплярах рабочей роли

  1. Откройте проект Load Test в среде Visual Studio.

  2. Настройте каждую рабочую роль с внутренними конечными точками TCP. Общие инструкции по добавлению конечных точек в роль см. в статье Как определить внутренние конечные точки для роли. Для каждой конечной точки укажите свой частный номер порта. В следующей таблице показаны конфигурации конечных точек для каждой роли. Обратите внимание, что все эти конечные точки являются частными портами, использующими протокол TCP.

     

    Имя роли Имя порта Номер порта

    Агент

    SQL

    1433

    Агент

    WFS

    137-445

    Агент

    Порт прослушивателя агента

    6910

    Агент

    AgentDownload

    80

    Контроллер

    SQL

    1433

    Контроллер

    WFS

    137-445

    Контроллер

    Контроллер

    6910

    Контроллер

    AgentDownload

    80

    Контроллер

    Порт прослушивателя контроллера

    6901

    Контроллер

    Агент

    6910

    Контроллер или рабочая станция

    Отзыв

    49152

  3. Настройте определенный порт, чтобы разрешить контроллеру отправлять сообщения агентам. Используйте следующий раздел реестра рабочей роли, в которой размещен контроллер:

    1. HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\VisualStudio\10.0\EnterpriseTools\QualityTools\ListenPortRange\PortRangeStart

    2. HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\VisualStudio\10.0\EnterpriseTools\QualityTools\ListenPortRange\PortRangeEnd

  4. В списке автоматического запуска рабочей роли укажите файл setupwfw.cmd.

  5. Удаленный рабочий стол для каждой роли и выполните следующие действия.

    1. Откройте следующий каталог: \Windows\System32\drivers\etc\

      Откройте файл hosts для изменения. Этот файл можно открыть с помощью Notepad.exe. Поместите файл hosts в каждой системе с именем узла и IP-адресом. Редактирование этого файла выполняется вручную. Чтобы найти IP-адрес роли, откройте окно командной строки в каждой роли и введите IPCONFIG. Пример файла Hosts:

    2. 
      # Copyright (c) 1993-2009 Microsoft Corp.
      #
      # This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
      #
      # This file contains the mappings of IP addresses to host names. Each
      # entry should be kept on an individual line. The IP address should
      # be placed in the first column followed by the corresponding host name.
      # The IP address and the host name should be separated by at least one
      # space.
      #
      # Additionally, comments (such as these) may be inserted on individual
      # lines or following the machine name denoted by a '#' symbol.
      #
      # For example:
      #
      #      102.54.94.97     rhino.acme.com          # source server
      #       38.25.63.10     x.acme.com              # x client host
      
      # localhost name resolution is handled within DNS itself.
      #127.0.0.1       localhost
      #::1             localhost
      10.115.222.131 RD00155D317984    # workstation
      10.115.218.125 RD00155D3175BF    # Controller
      10.115.222.142 RD001455316FEE    # Agent00
      10.115.196.26 RD00D32D6747       # Agent01
      10.115.228.52  RD000155D317EBD  # Agent02
      10.115.222.131 RD00155D317984    # Agent03
      
      
  6. Каждая роль может взаимодействовать с другими компонентами. Вы можете установить двоичные файлы в каждой системе. Чтобы ускорить этот процесс, разместите двоичные файлы в хранилище больших двоичных объектов. Кроме того, выполните дополнительные команды как часть задачи запуска. Дополнительные сведения см. в статье Как определить задачи запуска для роли.)

  7. В SQL Server создайте локальную учетную запись SQL, чтобы контроллер и рабочая станция могли обращаться к базе данных результатов. Затем настройте в репозитории использование этих учетных записей. Создайте базу данных при настройке контроллера и затем настройте ее для использования учетной записи из интегрированной среды разработки.


Дата сборки:

2013-07-25

Добавления сообщества

Корпорация Майкрософт проводит интернет-опрос, чтобы выяснить ваше мнение о веб-сайте MSDN. Если вы желаете принять участие в этом интернет-опросе, он будет отображен при закрытии веб-сайта MSDN.

Вы хотите принять участие?
Показ:
© 2014 Microsoft