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

2025-04-03

Идеи решения

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

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

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

Архитектура

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

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

Поток данных

Следующий поток данных соответствует предыдущей схеме:

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

Компоненты

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

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

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

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

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

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

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

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

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

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

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

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

Пользовательские плагины

В JMeter пользовательские подключаемые модули — это компоненты программного обеспечения, которые можно добавить для расширения функциональных возможностей по умолчанию. Пользовательские подключаемые модули добавляют новые возможности, функции или интеграции в JMeter. Вы можете разрабатывать пользовательские подключаемые модули с помощью языка программирования Java и пакета средств разработки подключаемых модулей JMeter (PDK). PDK предоставляет набор инструментов и API-интерфейсов, которые помогают создавать новые плагины, включая элементы графического интерфейса, прослушиватели и семплеры.

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

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

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

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

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

Создайте файл 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" estclass="com.microsoft.eventhubplugin.EventHubPlugin" testname="Azure Event Hubs Sampler" enabled="true">
                <!-- Azure Event Hub connection configuration using Managed Identity (see repository for instructions) -->
                <boolProp name="useManagedIdentity">true</boolProp>
                <stringProp name="eventHubNamespace">telemetry-ehn.servicebus.windows.net</stringProp>
                <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
                <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
            </com.microsoft.eventhubplugin.EventHubPlugin>
        </hashTree>
    </hashTree>
    </hashTree>
</jmeterTestPlan>

Реализация com.microsoft.eventhubplugin.EventHubPluginGui и com.microsoft.eventhubplugin.EventHubPlugin доступны в примерах Azure.

В файле задайте значения подключений Event Hubs с помощью назначенного управляемого удостоверения тестовых исполнителей. Это удостоверение должно иметь доступ на запись к экземпляру Центров обработки событий.
В файле задайте значение узла 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. Названия сэмплеров отображаются на панели мониторинга результатов нагрузочного тестирования. Пример шаблона жидкости вместе с файлом скрипта JMeter доступен для скачивания в примерах Azure.

Обновление пользовательского подключаемого модуля из Центров событий в Центр Интернета вещей

Настраиваемый подключаемый модуль использует Центры событий в качестве основного целевого ресурса. Следующая конфигурация — это настройка клиента ПАКЕТА SDK для Центров событий:

EventHubProducerClient producer = null;
EventHubClientBuilder producerBuilder = new EventHubClientBuilder();

producerBuilder.credential(getEventHubNamespace(), getEventHubName(), new DefaultAzureCredentialBuilder().build());
producer = producerBuilder.buildProducerClient();

EventDataBatch batch = producer.createBatch(new CreateBatchOptions());
batch.tryAdd(new EventData(msg));
producer.send(batch);

В следующем примере показано, как повторно использовать то же решение, добавить зависимости Интернета вещей и изменить клиент ПАКЕТА SDK для использования Центра Интернета вещей:

IotHubServiceClientProtocol protocol = IotHubServiceClientProtocol.AMQPS;
ServiceClient client = new ServiceClient(getIoTHostName(), new DefaultAzureCredentialBuilder().build(), protocol);
client.open();

Message message = new Message(msg);
client.send(getDeviceName(), message);

client.close();

Проведите нагрузочный тест, используя новый плагин.

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

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

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

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

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

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

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

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

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

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

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

Измерение ключевых показателей эффективности

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

Центры событий: Подход к тестированию производительности для концентратора событий заключается в отправке большого количества сообщений в концентратор событий, а затем измерять RPS и LOAD. RPS — это количество сообщений, отправляемых в концентратор событий в секунду. Load — это общее количество сообщений, отправляемых в концентратор событий во время тестирования производительности. Нагрузочное тестирование может измерять RPS и LOAD.
Функции Azure: Подход к тестированию производительности функций — измерять следующие метрики.
- ИКР (инфракрасное излучение)
- RT
- АМУ
- SR
- АРС
- DF

Azure Monitor может измерять AMU, ARS и DF, но не IR, RT или SR. Чтобы измерить ключевые показатели эффективности с помощью Azure Monitor, включите Application Insights для функций Azure. Для получения дополнительной информации см. Включение интеграции Application Insights.

После включения 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 на основе предыдущих запросов.

Заключение

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

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

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

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