Test de charge Azure avec des plug-ins personnalisés pour Event Hubs et IoT Hub

2025-04-03

Idées de solution

Cet article présente une idée de solution. Votre architecte cloud peut s’appuyer sur ces conseils pour visualiser les principaux composants d’une implémentation typique de cette architecture. Utilisez cet article comme point de départ pour concevoir une solution bien conçue qui répond aux exigences spécifiques de votre charge de travail.

Cette solution propose des recommandations concernant l’utilisation des tests de charge Azure, un service qui vous permet d’exécuter des scripts Apache JMeter et des plugins personnalisés pour simuler les comportements des utilisateurs et des appareils. Cette solution explique également comment concevoir des indicateurs de performance clés (KPI) et développer un tableau de bord pour surveiller et analyser les résultats du test de charge dans un exemple d’application avec Azure Functions et Azure Event Hubs. Cet exemple utilise Event Hubs, mais vous pouvez appliquer la même approche à Azure IoT Hub en remplaçant le client Event Hubs par le client IoT Hubs. Cet article suppose que vous connaissez JMeter, ses plug-ins et plug-ins personnalisés, et Functions et Event Hubs.

IoT Hub contient plus de composants principaux que Event Hubs, y compris les partitions. Par conséquent, l’approche de test de charge décrite dans cet article s’applique également à IoT Hub avec des modifications minimales.

Architecture

Pour effectuer des tests de charge, vous avez besoin d’un plan de test, qui est un ensemble d’instructions qui indiquent à JMeter ce qu’il faut faire pendant le test. Le plan de test peut inclure plusieurs scénarios de test, et chaque scénario peut avoir différents paramètres et configurations. Par exemple, vous pouvez avoir un scénario qui simule un seul utilisateur accédant à une application web et un autre scénario qui simule plusieurs utilisateurs qui accèdent simultanément à la même application.

Téléchargez un fichier Visio de cette architecture.

Flux de données

Le flux de données suivant correspond au diagramme précédent :

Un appareil simulé envoie des données à un hub d’événements via un agent de test de charge. Tout comportement de l’appareil peut être simulé à l’aide de plug-ins personnalisés JMeter. L’agent Load Testing envoie des données au hub d’événements après avoir exécuté le plug-in personnalisé pour n’importe quel type d’appareil simulé.
Le hub d’événements déclenche une application de fonction Azure qui traite les données et les envoie à d’autres services en aval, tels qu’Azure SQL Database et Azure Digital Twins.
Azure Monitor surveille l’application de fonction et Event Hubs.
Load Testing collecte les données d’Azure Monitor et les affiche dans un tableau de bord.

Composants

Cet exemple utilise les composants suivants :

test de charge: utilisez le test de charge pour exécuter des scripts Apache JMeter et des plug-ins personnalisés pour simuler les comportements des utilisateurs et des appareils. Load Testing fournit une interface web pour gérer et exécuter des tests de charge et un ensemble d’API pour automatiser le processus. Le test de charge est un service entièrement managé, ce qui signifie que vous n’avez pas besoin de gérer les serveurs ou l’infrastructure. Dans cette architecture, Load Testing télécharge les scripts JMeter et les plug-ins personnalisés, et c'est sur cet environnement de calcul que ces scripts s'exécutent.
Event Hubs: Event Hubs est un service de traitement des événements cloud que vous pouvez utiliser pour collecter, traiter et analyser des événements et diffuser en continu des données à partir de différentes sources en temps réel. Event Hubs prend en charge plusieurs protocoles, notamment Advanced Message Queuing Protocol (AMQP), HTTPS, Kafka protocol, Message Queuing Telemetry Transport (MQTT) et AMQP sur WebSocket. Cette architecture est basée sur des événements. Le test de charge remplit donc les événements pour tester la charge de travail.
IoT Hub: IoT Hub est un service géré hébergé dans le cloud qui sert de hub de messages central pour la communication entre une application IoT et ses appareils attachés. Vous pouvez connecter des millions d’appareils et leurs solutions back-end de manière fiable et sécurisée. Presque n’importe quel appareil peut être connecté à un hub IoT. Vous pouvez adapter cette architecture pour utiliser IoT Hub en remplaçant le client Event Hubs par le client IoT Hub.
Azure Functions: Functions est un service de calcul serverless que vous pouvez utiliser pour exécuter du code sans avoir à gérer les serveurs ou l’infrastructure. Il prend en charge plusieurs langages de programmation dont C#, F#, Java, JavaScript, PowerShell, Python et TypeScript. Cette architecture utilise Functions comme niveau de calcul principal. Les données d’événements dans Event Hubs déclenchent et effectuent un scale-out des applications de fonction.
interface graphique JMeter: Une interface graphique JMeter est un outil de test de charge open source principalement utilisé pour tester les performances des applications web. Toutefois, vous pouvez également l’utiliser pour tester d’autres types d’applications, tels que les services web SOAP et REST, les serveurs FTP et les bases de données.
Azure Monitor : Azure Monitor fournit des capacités de surveillance et d’alerte pour les ressources Azure. Utilisez-le pour surveiller les performances et l’intégrité de vos applications et de l’infrastructure sous-jacente. Dans cette architecture, Azure Monitor surveille l’intégrité des composants d’infrastructure Azure pendant le test de charge.

Détails du scénario

Vous pouvez utiliser load Testing pour appliquer un script Apache JMeter existant et exécuter un test de charge à l’échelle du cloud sur n’importe quelle ressource Azure.

JMeter permet aux testeurs de créer et d’exécuter des tests de charge, des tests de contrainte et des tests fonctionnels. Il simule plusieurs utilisateurs qui accèdent simultanément à une application web afin que les testeurs puissent identifier les goulots d’étranglement potentiels des performances ou d’autres problèmes susceptibles de survenir sous de lourdes charges. Vous pouvez utiliser JMeter pour mesurer différentes métriques de performances, telles que le temps de réponse, le débit et le taux d’erreur.

JMeter utilise une interface graphique graphique pour permettre aux utilisateurs de créer des plans de test, qui peuvent inclure plusieurs scénarios de test qui ont différents paramètres et configurations. Les testeurs peuvent également personnaliser JMeter à l’aide de plug-ins ou en écrivant du code personnalisé. Les plug-ins peuvent aider les utilisateurs à travailler avec des services qui utilisent des protocoles non HTTP, tels que AMQP et WebSocket.

JMeter fournit un large éventail de fonctionnalités et de fonctions pour les tests de charge, mais les fonctionnalités intégrées peuvent ne pas couvrir des cas d’usage ou des exigences spécifiques. En développant des plug-ins personnalisés, les testeurs peuvent ajouter de nouvelles fonctionnalités ou personnaliser les fonctionnalités existantes en fonction de leurs besoins.

Par exemple, vous pouvez développer un plug-in personnalisé pour simuler un type spécifique de comportement utilisateur ou générer des données de test plus réalistes. Vous pouvez également développer des plug-ins personnalisés pour intégrer JMeter à d’autres outils ou systèmes, tels que la journalisation et les outils de création de rapports, l’intégration continue et le déploiement continu (CI/CD). Les plugins personnalisés peuvent aider à rationaliser le processus de test et à faciliter l’intégration des tests de charge dans le flux de travail global de développement logiciel. Ils permettent aux testeurs d’adapter JMeter à leurs besoins spécifiques et d’améliorer la précision et l’efficacité de leurs efforts de test de charge.

Dans cet exemple, un appareil signale la température et l’humidité sur une période spécifique. L’exemple simule ce comportement à l’aide d’un plug-in JMeter personnalisé. L’implémentation actuelle du plug-in personnalisé génère des données aléatoires à l’aide d’un modèle fourni. Toutefois, le plug-in peut contenir n’importe quel comportement complexe possible pour n’importe quel appareil. Dans cet exemple, l’appareil envoie les données à un hub d’événements dans Azure. Le hub d’événements déclenche une application de fonction Azure qui traite les données et les envoie à d’autres services en aval, tels que SQL Database. Azure Functions est le service que l’architecture teste. Le plan de test est conçu pour simuler le comportement de l’appareil et envoyer des données au hub d’événements.

Cas d’usage potentiels

L’utilisation du test de charge avec des plug-ins personnalisés peut être utile dans différents scénarios, tels que :

Test des performances d’une application qui utilise des protocoles non HTTP, tels que AMQP et WebSocket.
Tester la performance d’une application qui utilise un protocole personnalisé.
Tester la performance d’une application qui utilise un SDK non Microsoft.
Simulation d’un type spécifique de comportement de l’utilisateur ou de l’appareil.
Génération de données de test plus réalistes.

Plug-ins personnalisés

Dans JMeter, les plug-ins personnalisés sont des composants logiciels que vous pouvez ajouter pour développer ses fonctionnalités par défaut. Les plug-ins personnalisés ajoutent de nouvelles fonctionnalités, fonctions ou intégrations à JMeter. Vous pouvez développer des plug-ins personnalisés à l’aide du langage de programmation Java et du kit de développement de plug-in JMeter (PDK). Le PDK fournit un ensemble d’outils et d’API qui vous aident à créer de nouveaux plug-ins, notamment des éléments gui, des écouteurs et des échantillonneurs.

Pour implémenter un échantillonneur personnalisé pour Event Hubs dans JMeter, veuillez suivre les instructions fournies dans Plugins JMeter Test de charge. Après avoir implémenté votre échantillonneur personnalisé, vous pouvez l’utiliser dans votre plan de test JMeter dans Le test de charge comme n’importe quel autre échantillonneur.

Vous pouvez implémenter un plan de test à l’aide d’un groupe de threads qui contrôle le nombre de threads, tels que les utilisateurs virtuels et les appareils, pour exécuter un scénario spécifique. Chaque groupe de threads peut avoir des paramètres différents pour le nombre de threads, la période de montée en charge, le nombre de boucles et la durée. Les groupes de threads peuvent s’exécuter séquentiellement ou en parallèle, en fonction de la configuration du plan de test et des exigences de l’application. Vous pouvez ajouter l’échantillonneur à un groupe de threads, définir ses paramètres et le configurer selon les besoins. Les échantillonneurs personnalisés peuvent être des outils puissants dans JMeter qui vous permettent de simuler des scénarios complexes et des demandes que les échantillonneurs intégrés ne prennent pas en charge.

Créer un script Apache JMeter avec un plug-in personnalisé

Dans cette section, vous créez un script de test JMeter pour tester la charge d’une application avec Event Hubs.

Pour créer un échantillon de script de test JMeter :

Créez un fichier LoadTest.jmx dans un éditeur de texte et collez l’extrait de code suivant dans le fichier. Ce script simule un test de charge de 36 machines virtuelles qui envoient simultanément des événements à un hub d’événements. La fin de l’opération prend 10 minutes.

<?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>

L’implémentation de com.microsoft.eventhubplugin.EventHubPluginGui et com.microsoft.eventhubplugin.EventHubPlugin est disponible sur Exemples Azure.

Dans le fichier, définissez les valeurs de connexion Event Hubs à l’aide de l’identité managée affectée des exécuteurs de test. Cette identité doit avoir un accès en écriture à l’instance Event Hubs.
Dans le fichier, définissez la valeur du nœud eventHubName sur le nom du hub d’événements, tel que telemetry-data-changed-eh.
Définissez la valeur du nœud liquidTemplateFileName sur le fichier qui contient le message envoyé au hub d’événements. Par exemple, créez un fichier nommé StreamingDataTemplate.liquid comme suit :
```
{
    {% 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 }}
}
```
Dans cet exemple, la charge utile du message event Hub est un objet JSON qui a trois propriétés, MachineId, Temperatureet Humidity. MachineId est un ID généré de manière aléatoire de 27 caractères, et Temperature et Humidity sont des entiers aléatoires inférieurs à 100. Ce fichier utilise la syntaxe du modèle Liquid. Le modèle Liquid est un langage de création de modèles populaire utilisé dans divers frameworks de développement web. Les modèles Liquid permettent aux développeurs de créer un contenu dynamique qui peut être facilement mis à jour et modifié. Ils vous permettent d’insérer des variables, des conditions, des boucles et d’autres éléments dynamiques dans vos messages de hub d’événements. La syntaxe est simple et il existe de nombreuses ressources en ligne disponibles pour vous aider à démarrer. Les modèles Liquid offrent un moyen puissant et flexible de créer des messages dynamiques et personnalisables.
Enregistrez et fermez le fichier.

Importante

N’incluez aucune donnée personnelle dans le nom de l’échantillonneur dans le script JMeter. Les noms de l’échantillonneur apparaissent dans le tableau de bord des résultats des tests de test Load Testing. Un exemple de modèle liquide, ainsi que le fichier de script JMeter, est disponible au téléchargement sur exemples Azure.

Mettre à jour le plug-in personnalisé d’Event Hubs vers IoT Hub

Le plug-in personnalisé utilise Event Hubs comme ressource cible principale. La configuration suivante est la configuration du client sdk pour Event Hubs :

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);

L’exemple suivant montre comment réutiliser la même solution, ajouter les dépendances IoT et modifier le client sdk pour utiliser IoT Hub :

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();

Exécuter le test de charge à l’aide du nouveau plug-in

Lorsque le test de charge démarre votre test de charge, il déploie d’abord le script JMeter avec tous les autres fichiers sur les instances du moteur de test. Avant d’exécuter le test, accédez à l’onglet paramètres pour définir les paramètres requis. Pour plus d’informations, consultez Personnaliser un test de charge avec les plug-ins Apache JMeter et le test de charge.

Configurer des tests de performances pour l’environnement

Pour les tests de performances, il est important que votre environnement de test soit similaire à l’environnement de production. Cet exemple utilise l’environnement suivant pour les tests de performances afin de mieux comprendre la capacité et les performances du système.

Service	Paramétrage
Event Hubs	Premium avec une unité de traitement
Les fonctions Azure	Linux avec plan Premium (EP1) - 210 ACU, 3,5 Go de mémoire et 1 processeur virtuel équivalent Standard_D1_v2
Région	USA Est

Le choix du niveau de service approprié pour n’importe quel service Azure, y compris Event Hubs et Azure Functions, est un processus complexe et dépend de nombreux facteurs. Pour plus d’informations, veuillez consulter Tarification d’Event Hubs et Tarification des fonctions.

Concevoir des indicateurs de performance clés pour les tests de performances

Avant de pouvoir concevoir des indicateurs de performance clés pour les tests de performances, vous devez définir les exigences métier et l’architecture système. Les exigences métier vous indiquent quels indicateurs de performance clés, tels que le temps de réponse, le débit ou le taux d’erreur, que vous souhaitez mesurer. L’architecture du système vous indique comment tester la performance de chaque composant, tels que les serveurs Web, les bases de données ou les API. Cela vous aide également à choisir la meilleure stratégie de test de performance, telle que le test de charge, le test de stress ou le test d’endurance.

Cet exemple présente les exigences métier suivantes :

Le système peut gérer 1 000 requêtes par seconde.
La fiabilité du système est supérieure à 0,99.
Le système peut gérer 1 000 appareils simultanés signalant leurs informations de données personnelles.
Vous pouvez spécifier la capacité maximale du système en termes de nombre d’appareils qu’il peut prendre en charge. Par exemple, le système peut prendre en charge 1 000 appareils simultanés avec trois fois la capacité actuelle.

Pour déterminer si le système répond à ces exigences, vous pouvez utiliser les indicateurs de performance clés suivants pour les tests de performances :

Indicateur de performance clé	Descriptif
RPS	Demandes par seconde pour un hub d’événements
CHARGER	Nombre de charges ou de requêtes envoyées au hub d’événements pendant les tests de performance
IR	Nombre d’appels de fonction ou taux d'ingestion
RT	Temps moyen pour l’exécution d’Azure Functions
UMA	Utilisation moyenne de la mémoire pour Azure Functions
SR	Taux de réussite de tous les appels d’application de fonction
ARS	Temps de réponse moyen du service en aval pour les services tels que SQL Server ou un microservice
DF	Nombre d’échecs de dépendance, y compris les erreurs d’application de fonction interne
MRPS	RPS maximal sans backlog dans le hub d’événements (capacité du système)

Mesurer les indicateurs de performance clés

Pour mesurer les KPI, vous devez avoir une stratégie de test de performance. La stratégie définit l’approche de test de performance pour chaque composant. Cet exemple utilise la stratégie de test de performances suivante.

Event Hubs : L’approche de test des performances pour le hub d’événements consiste à envoyer de nombreux messages au hub d’événements, puis à mesurer le RPS et LOAD. Le RPS est le nombre de messages envoyés au hub d’événements par seconde. La CHARGE est le nombre total de messages envoyés au hub d’événements pendant les tests de performance. Les tests de charge peuvent mesurer RPS et LOAD.
Azure Functions : L’approche de test des performances pour Functions consiste à mesurer les métriques suivantes.
- IR
- RT
- UMA
- SR
- ARS
- DF

Azure Monitor peut mesurer AMU, ARS et DF, mais pas IR, RT ou SR. Pour mesurer les indicateurs de performance clés à l’aide d’Azure Monitor, activez Application Insights pour Azure Functions. Pour plus d’informations, veuillez consulter la section Activer l’intégration d’Application Insights.

Après avoir activé Azure Monitor, vous pouvez utiliser les requêtes suivantes pour mesurer les indicateurs de performance clés :

IR: 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

Exemple de tableau de bord Azure Monitor

L’image suivante montre un exemple du tableau de bord Azure Monitor. Il affiche les indicateurs de performance clés pour Azure Functions en fonction des requêtes précédentes.

Conclusion

Dans cet article, vous avez appris à concevoir des indicateurs de performance clés et à développer un tableau de bord pour le test de charge. Vous avez également appris à utiliser des plugins personnalisés dans JMeter pour effectuer des tests de charge sur Azure Functions intégrées avec Event Hubs. Vous pouvez utiliser la même approche pour effectuer des tests de charge sur d’autres services Azure. Vous pouvez également configurer un pipeline CI/CD pour vos scripts de test de charge à l’aide d’Azure DevOps.

Pour plus d’informations, consultez le test de charge .

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

Mahdi Setayesh | Ingénieur logiciel principal
Oscar Fimbres | Ingénieur logiciel senior

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Partager via