Нагрузочное тестирование Azure с пользовательскими подключаемыми модулями

Статья
01/27/2024

Идеи решения

Эта статья является идеей решения. Если вы хотите расширить содержимое с дополнительными сведениями, такими как потенциальные варианты использования, альтернативные службы, рекомендации по реализации или рекомендации по ценам, сообщите нам, предоставив отзыв GitHub.

Это решение содержит рекомендации по использованию Нагрузочного тестирования Azure, службы, которая позволяет запускать скрипты Apache JMeter и пользовательские подключаемые модули для имитации поведения пользователей и устройств. Это решение также объясняет, как разрабатывать ключевые показатели эффективности и разрабатывать панель мониторинга для мониторинга и анализа результатов нагрузочного теста в примере приложения с Функции Azure и Центры событий Azure. В статье предполагается, что у вас есть некоторое знакомство с JMeter, его подключаемыми модулями и пользовательскими подключаемыми модулями, а также Функции Azure и Центрами событий.

Архитектура

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

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

Скачайте файл Visio для этой архитектуры.

Поток данных

В этом примере поток данных выглядит следующим образом:

Имитированное устройство отправляет данные в концентратор событий через агент Azure Load Testing. Любое поведение устройства можно имитировать с помощью пользовательских подключаемых модулей JMeter. Агент нагрузочного теста Azure отвечает за отправку данных в концентратор событий после запуска настраиваемого подключаемого модуля для любых типов имитированных устройств.
Концентратор событий активирует функцию Azure, которая отвечает за обработку данных, а затем отправляет данные в другие подчиненные службы, такие как База данных SQL Azure и Azure Digital Twins.
Служба Azure Monitor используется для мониторинга функций и центров событий Azure.
Служба нагрузочного тестирования Azure собирает данные из службы Azure Monitor, а затем отображает ее на панели мониторинга.

Компоненты

В этом примере используются следующие компоненты:

Нагрузочное тестирование Azure. Нагрузочное тестирование Azure позволяет запускать скрипты Apache JMeter и пользовательские подключаемые модули для имитации поведения пользователей и устройств. Он предоставляет веб-интерфейс для управления нагрузочных тестов и набора API, которые можно использовать для автоматизации процесса. Нагрузочное тестирование Azure — это полностью управляемая служба, что означает, что вам не нужно беспокоиться об управлении серверами или инфраструктурой. Вы можете передать скрипты JMeter и пользовательские подключаемые модули, а azure Load Testing обрабатывает остальные.
Центры событий Azure: Центры событий Azure — это облачная служба обработки событий, которую можно использовать для сбора, обработки и анализа событий и потоковой передачи данных из различных источников в режиме реального времени. Центры событий поддерживают несколько протоколов, включая ПРОТОКОЛ AMQP (расширенный протокол очереди сообщений), HTTPS, Протокол Kafka, MQTT (транспорт телеметрии очереди сообщений) и AMQP через WebSockets. Выбор правильного протокола зависит от нескольких факторов, включая тип данных, с которыми вы работаете, конкретные требования приложения, а также возможности и ограничения самих протоколов.
Функции Azure: Функции Azure — это бессерверная служба вычислений, которая позволяет запускать код без необходимости управлять серверами или инфраструктурой. Он поддерживает несколько языков программирования, включая C#, F#, Java, JavaScript, PowerShell, Python и TypeScript. Функции Azure можно использовать для обработки событий и потоковой передачи данных из Центров событий, а также других источников, таких как служба хранилища Azure и Azure Cosmos DB.
JMeter GUI: JMeter GUI — это средство нагрузочного тестирования с открытым исходным кодом, которое в основном используется для тестирования производительности веб-приложений. Изначально он был разработан для тестирования веб-приложений. Однако его также можно использовать для тестирования других типов приложений, таких как веб-службы SOAP и REST, FTP-серверы и базы данных.
Azure Monitor: Azure Monitor предоставляет возможности мониторинга и оповещения для ресурсов Azure. Он позволяет отслеживать производительность и работоспособность приложений и базовой инфраструктуры. Azure Monitor можно использовать для мониторинга центров событий и Функции Azure, а также других служб Azure, таких как служба хранилища Azure и Azure Cosmos DB.

Подробности сценария

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

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

JMeter использует интерфейс на основе графического интерфейса, чтобы разрешить пользователям создавать тестовые планы, которые могут включать несколько сценариев тестирования, каждый из которых имеет разные параметры и конфигурации. Тестировщики также могут настроить JMeter с помощью подключаемых модулей или написать пользовательский код, что позволяет им расширить функциональные возможности за рамки. Подключаемые модули могут помочь нам работать со службами, используюющими протоколы, отличные от HTTP, такие как AMQP и Websocket.

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

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

В этом примере предполагается, что устройство, которое сообщает о температуре и влажности за заданный период времени. Мы можем имитировать это простое поведение с помощью настраиваемого подключаемого модуля JMeter. В текущей реализации пользовательского подключаемого модуля, предоставленного здесь, мы создадим случайные данные с помощью предоставленного шаблона. Однако подключаемый модуль может содержать любое возможное сложное поведение для любых устройств. В этом примере устройство отправляет данные в концентратор событий в Azure. Концентратор событий активирует функцию Azure, которая отвечает за обработку данных, а затем отправляет данные в другие подчиненные службы, например База данных SQL Azure. Функция Azure — это служба, которую мы хотим протестировать. План тестирования предназначен для имитации поведения устройства и отправки данных в концентратор событий.

Потенциальные варианты использования

Использование нагрузочного тестирования Azure с пользовательскими подключаемыми модулями может быть полезно в различных сценариях, таких как:

Тестирование производительности приложения, использующего протоколы, отличные от HTTP, например AMQP и Websocket.
Тестирование производительности приложения, использующего пользовательский протокол.
Тестирование производительности приложения, использующего пакет SDK, отличный от Майкрософт.
Имитация определенного типа поведения пользователя или устройства или создание более реалистичных тестовых данных.

Пользовательские подключаемые модули

Пользовательские подключаемые модули в контексте JMeter — это компоненты программного обеспечения, которые можно добавить в JMeter, чтобы расширить функциональные возможности за рамки. Пользователи или разработчики, отличные от Майкрософт, могут разрабатывать пользовательские подключаемые модули для добавления новых функций, функций или интеграции в JMeter. Пользовательские подключаемые модули можно разрабатывать с помощью языка программирования Java и пакета средств разработки подключаемых модулей JMeter (PDK). PDK предоставляет набор средств и API, которые упрощают создание новых подключаемых модулей, включая элементы ГРАФИЧЕСКОго интерфейса, прослушиватели и образцы.

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

Чтобы реализовать пользовательский пример для Центров событий в JMeter, следуйте инструкциям, приведенным в подключаемых модулях Azure Load Testing. После реализации пользовательского примера его можно использовать в плане тестирования JMeter в нагрузочном тесте Azure так же, как и любой другой пример.

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

Создание скрипта Apache JMeter с помощью пользовательского подключаемого модуля

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

Чтобы создать пример тестового скрипта JMeter, выполните следующие действия.

Создайте файл LoadTest.jmx на локальном компьютере:
```
touch LoadTest.jmx
```

Откройте LoadTest.jmx в текстовом редакторе и вставьте следующий фрагмент кода в файл. Этот скрипт имитирует нагрузочный тест 36 виртуальных машин, которые одновременно отправляют события в концентратор событий и занимает 10 минут:

<?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="5.0" jmeter="5.5">
    <hashTree>
    <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true">
        <stringProp name="TestPlan.comments"></stringProp>
        <boolProp name="TestPlan.functional_mode">false</boolProp>
        <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
        <boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
        <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
        <collectionProp name="Arguments.arguments"/>
        </elementProp>
        <stringProp name="TestPlan.user_define_classpath"></stringProp>
    </TestPlan>
    <hashTree>
        <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true">
        <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
        <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
            <boolProp name="LoopController.continue_forever">false</boolProp>
            <intProp name="LoopController.loops">-1</intProp>
        </elementProp>
        <stringProp name="ThreadGroup.num_threads">36</stringProp>
        <stringProp name="ThreadGroup.ramp_time">20</stringProp>
        <boolProp name="ThreadGroup.scheduler">true</boolProp>
        <stringProp name="ThreadGroup.duration">600</stringProp>
        <stringProp name="ThreadGroup.delay"></stringProp>
        <boolProp name="ThreadGroup.same_user_on_next_iteration">false</boolProp>
        </ThreadGroup>
        <hashTree>
        <com.microsoft.eventhubplugin.EventHubPlugin guiclass="com.microsoft.eventhubplugin.EventHubPluginGui" testclass="com.microsoft.eventhubplugin.EventHubPlugin" testname="Azure Event Hubs Sampler" enabled="true">
            <stringProp name="eventHubConnectionVarName">EventHubConnectionString</stringProp>
            <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
            <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
        </com.microsoft.eventhubplugin.EventHubPlugin>
        <hashTree/>
        </hashTree>
    </hashTree>
    </hashTree>
</jmeterTestPlan>

Реализация com.microsoft.eventhubplugin.EventHubPluginGui и com.microsoft.eventhubplugin.EventHubPlugin доступность в Azure Samples.

В файле задайте для узла значение переменнойeventHubConnectionVarName, указывающее центры событий строка подключения узле. Например, если требуется, чтобы переменная среды, в которой хранятся строка подключения центров EventHubConnectionStringсобытий, задайте для этой переменной EventHubConnectionString значение и задайте значение переменной среды.

Важно!

Перед запуском скрипта нагрузочного теста убедитесь, что значение EventHubConnectionString задано как часть процесса создания нагрузочного теста Azure.
В файле задайте для узла имя концентратора eventHubName событий, например telemetry-data-changed-eh.
Задайте для узла значение liquidTemplateFileName файла, содержащего сообщение, которое отправляется в концентратор событий. Например, создайте файл с именем StreamingDataTemplate.liquid :
```
{
    {% assign numberOfMachines = 36 %}
    {% assign machineId = dataGenerator.randomNaturalNumber | modulo: numberOfMachines %}
    "MachineId": "{{machineId | prepend: '0000000000000000000000000000000000000000' | slice: -27, 27 }}"
    "Temperature": {{dataGenerator.randomInt | modulo: 100 }},
    "Humidity": {{dataGenerator.randomInt | modulo: 100 }}
}
```
В этом примере полезные данные для сообщения концентратора событий — это объект JSON с тремя свойствами, включая MachineId, Temperatureи Humidity где MachineId случайным образом сформирован идентификатор длиной 27, а TemperatureHumidity также случайные целые числа менее 100. Этот файл представляет собой синтаксис шаблона liquid. Шаблон Liquid — это популярный язык шаблонов, используемый в различных платформах разработки веб-приложений. Шаблоны Liquid позволяют разработчикам создавать динамическое содержимое, которое можно легко обновлять и изменять. Они позволяют вставлять переменные, условия, циклы и другие динамические элементы в сообщения концентратора событий. Синтаксис прост, и есть много онлайн-ресурсов, которые помогут вам приступить к работе. В целом шаблоны Liquid предлагают мощный и гибкий способ создания динамических настраиваемых сообщений.
Сохранить и закрыть файл.

Важно!

Не включайте персональные данные в имя примера в скрипт JMeter. Имена примеров отображаются на панели мониторинга результатов теста нагрузочного тестирования Azure. Пример шаблона жидкости вместе с файлом скрипта JMeter доступен для скачивания в Azure Samples

Запуск нагрузочного теста с помощью нового подключаемого модуля

Когда нагрузочное тестирование Azure запускает нагрузочный тест, он сначала развертывает скрипт JMeter вместе со всеми другими файлами на экземплярах тестового модуля, а затем запускает нагрузочный тест, как описано в разделе "Настройка нагрузочного теста с помощью подключаемых модулей Apache JMeter" и Azure Load Testing. Перед выполнением теста перейдите на вкладку параметров, определите EventHubConnectionStringи предоставьте строка подключения концентратору событий.

Настройка тестирования производительности для среды

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

В примере архитектуры можно использовать следующие службы для тестирования производительности:

Service	Настройка
Eventhub	Премиум с одним блоком обработки (PU).
функции Azure;	Linux с планом Premium (EP1) — 210 ACU, 3,5 ГБ памяти и 1 виртуальным ЦП эквивалентным Standard_D1_v2
Регион	Восточная часть США

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

Проектирование ключевых показателей эффективности для тестирования производительности

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

В этом примере бизнес-требования:

Система должна обрабатывать 1000 запросов в секунду.
Надежность системы должна быть выше 0,99.
Система должна иметь возможность обрабатывать 1000 одновременных устройств, сообщающих свои персональные данные.
Указание максимальной емкости системы с точки зрения количества поддерживаемых устройств. Например, может ли система с 3x текущей емкости поддерживать 1000 одновременных устройств?

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

КПЭ	Description
RPS	Запрос в секунду для концентратора событий
LOAD	Количество загрузок или запросов, отправленных в концентратор событий во время тестирования производительности
IR	Количество выполнений функций или скорость приема
RT	Среднее время выполнения функции Azure
АМУ	Среднее использование памяти для Функции Azure
SR	Частота успешного выполнения всех функций
ARS	Среднее время отклика нижестоящей службы (например, SQL Server или микрослужба)
DF	Число сбоев зависимостей, включая внутренние ошибки функции Azure
MRPS	Максимальное количество RPS без невыполненной работы в концентраторе событий (емкость системы)

Как измерять ключевые показатели эффективности

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

Центры событий. Подход к тестированию производительности для концентратора событий заключается в отправке большого количества сообщений в концентратор событий, а затем измерять RPS и LOAD. RPS — это количество сообщений, отправляемых в концентратор событий в секунду. Load — это общее количество сообщений, отправляемых в концентратор событий во время тестирования производительности. Служба нагрузочного тестирования Azure может измерять RPS и LOAD.
Функции Azure. Подход к тестированию производительности для Функции Azure заключается в измерении следующих метрик:
- Ir — это количество выполнения функций или скорость приема.
- Rt — это среднее время выполнения функции Azure.
- AMU — это среднее использование памяти для Функции Azure.
- Sr — это частота успешного выполнения всех функций.
- ARS — это среднее время ответа нижестоящей службы.
- DF — это число сбоев зависимостей, включая внутренние ошибки функций Azure.
- Служба Azure Monitor может измерять AMU, ARS и DF, но не IR, RT или SR.

Чтобы измерить ключевые показатели эффективности с помощью службы Azure Monitor, необходимо включить Аналитика приложений для Функции Azure. Дополнительные сведения см. в разделе "Включение интеграции приложений Аналитика".

После включения службы Azure Monitor можно использовать следующие запросы для измерения ключевых показателей эффективности.

ИК: FunctionAppLogs | where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize count() by FunctionName, Level, bin(TimeGenerated, 1h) | order by FunctionName desc
RT: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed "| parse Message with "Executed " Name " (" Result ", Id=" Id ", Duration=" Duration:long "ms)"| project TimeGenerated, Message, FunctionName, Result, FunctionInvocationId, Duration
SR: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize Success=countif(Level == "Information" ), Total=count() by FunctionName| extend Result=Success*100.0/Total| project FunctionName, Result| order by FunctionName desc

Пример панели мониторинга Azure Monitor

Ниже приведен пример панели мониторинга Azure Monitor, где показаны ключевые показатели эффективности для Функции Azure на основе запросов:

Заключение

В этой статье вы узнали, как разрабатывать ключевые показатели эффективности и разрабатывать панель мониторинга для нагрузочного теста Azure. Вы также узнали, как использовать пользовательские подключаемые модули в JMeter для выполнения нагрузочного тестирования на Функции Azure интегрированных с Центрами событий. Вы можете использовать тот же подход для выполнения нагрузочного тестирования в других службах Azure. Вы также можете настроить конвейер непрерывной интеграции и доставки (CI/CD) для скриптов нагрузочного тестирования с помощью Azure DevOps.

Дополнительные сведения см. в статье о нагрузочном тестировании Azure.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Автор субъекта:

Махди Сетайеш | Главный инженер программного обеспечения

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Share via

Нагрузочное тестирование Azure с пользовательскими подключаемыми модулями

Архитектура

Поток данных

Компоненты

Подробности сценария

Потенциальные варианты использования

Пользовательские подключаемые модули

Создание скрипта Apache JMeter с помощью пользовательского подключаемого модуля

Запуск нагрузочного теста с помощью нового подключаемого модуля

Настройка тестирования производительности для среды

Проектирование ключевых показателей эффективности для тестирования производительности

Как измерять ключевые показатели эффективности

Пример панели мониторинга Azure Monitor

Заключение

Соавторы

Следующие шаги

Обратная связь

Обратная связь

Дополнительные ресурсы

Share via

Нагрузочное тестирование Azure с пользовательскими подключаемыми модулями

Архитектура

Поток данных

Компоненты

Подробности сценария

Потенциальные варианты использования

Пользовательские подключаемые модули

Создание скрипта Apache JMeter с помощью пользовательского подключаемого модуля

Запуск нагрузочного теста с помощью нового подключаемого модуля

Настройка тестирования производительности для среды

Проектирование ключевых показателей эффективности для тестирования производительности

Как измерять ключевые показатели эффективности

Пример панели мониторинга Azure Monitor

Заключение

Соавторы

Следующие шаги

Связанные ресурсы

Обратная связь

Обратная связь

Дополнительные ресурсы