Test de charge Azure avec des plug-ins personnalisés

Article
01/31/2024

Idées de solution

Cet article présente une idée de solution. Si vous souhaitez nous voir développer le contenu avec d’autres informations, telles que des cas d’usage potentiels, d’autres services, des considérations d’implémentation ou un guide des prix, faites-le-nous savoir avec les Commentaires de GitHub.

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 une application exemple avec Azure Functions et Azure Event Hubs. Avant d’aborder cet article, il est préférable de se familiariser avec JMeter, ses plugins et plugins personnalisés, ainsi qu’avec Azure Functions et Event Hubs.

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, chacun avec des paramètres et configurations différents. Par exemple, vous pourriez avoir un scénario qui simule un seul utilisateur accédant à une application web, et un autre scénario qui simule plusieurs utilisateurs accédant simultanément à la même application.

Le plan de test peut également inclure plusieurs cas, chacun avec des paramètres et configurations différents. Dans notre cas, nous supposons qu’il y a un appareil qui relève la température et l’humidité sur une période donnée. L’appareil envoie les données à un hub d’événements dans Azure. Le hub d’événements déclenche une Azure Function qui est responsable du traitement des données puis de l’envoi des données à d’autres services en aval tels que la base de données Azure SQL. La Azure Function est le service que nous voulons tester. Le plan de test est conçu pour simuler le comportement de l’appareil et envoyer des données au hub d’événements.

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

Dataflow

Dans cet exemple, le flux de données est le suivant :

Un appareil simulé envoie des données à un hub d’événements via l’agent de test de charge Azure. Tout comportement de l’appareil peut être simulé à l’aide de plugins JMeter personnalisés. L’agent de test de charge Azure est responsable de l’envoi des données au hub d’événements après avoir exécuté le plugin personnalisé pour tout type d’appareils simulés.
Le hub d’événements déclenche une Azure Function qui est responsable du traitement des données puis de l’envoi des données à d’autres services en aval, tels que la base de données Azure SQL et Azure Digital Twins.
Le service Azure Monitor est utilisé pour surveiller la Azure Function et les Event Hubs.
Le service de test de charge Azure collecte les données du service Azure Monitor puis les affiche dans un tableau de bord.

Composants

Dans cet exemple, les composants suivants sont utilisés :

Test de charge Azure : Les tests de charge Azure vous permettent d’exécuter des scripts Apache JMeter et des plugins personnalisés pour simuler les comportements des utilisateurs et des appareils. Il fournit une interface web pour gérer et exécuter des tests de charge et un ensemble d’API qui peuvent être utilisées pour automatiser le processus. Les tests de charge Azure sont un service entièrement géré, ce qui signifie que vous n’avez pas à vous soucier de la gestion des serveurs ou de l’infrastructure. Vous pouvez télécharger vos scripts JMeter et plugins personnalisés, et les tests de charge Azure s’occupent du reste.
Azure Event Hubs : Azure Event Hubs est un service de traitement d’événements basé sur le cloud qui peut être utilisé pour collecter, traiter et analyser des événements et des données en streaming de diverses sources en temps réel. Event Hubs prend en charge plusieurs protocoles, dont AMQP (Advanced Message Queuing Protocol), HTTPS, le protocole Kafka, MQTT (Message Queuing Telemetry Transport) et AMQP sur WebSockets. Choisir le bon protocole dépend de plusieurs facteurs qui incluent le type de données avec lequel vous travaillez, les exigences spécifiques de votre application et les capacités et limitations des protocoles eux-mêmes.
Azure Functions: Azure Functions est un service de calcul sans serveur qui vous permet d’exécuter du code sans avoir à gérer des serveurs ou de l’infrastructure. Il prend en charge plusieurs langages de programmation dont C#, F#, Java, JavaScript, PowerShell, Python et TypeScript. Azure Functions peut être utilisé pour traiter des événements et des données en streaming provenant d’Event Hubs, ainsi que d’autres sources comme Azure Storage et Azure Cosmos DB.
Interface utilisateur JMeter : JMeter GUI est un outil de test de charge open source principalement utilisé pour tester la performance des applications web. Il a été initialement développé pour tester des applications web. Cependant, il peut également être utilisé pour tester d’autres types d’applications, telles 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. Il vous permet de surveiller la performance et la santé de vos applications ainsi que l’infrastructure sous-jacente. Azure Monitor peut être utilisé pour surveiller Event Hubs et Azure Functions, ainsi que d’autres services Azure comme Azure Storage et Azure Cosmos DB.

Détails du scénario

Les tests de charge Azure vous permettent de prendre un script Apache JMeter existant et de l’utiliser pour 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 stress et des tests fonctionnels. Il simule plusieurs utilisateurs accédant simultanément à une application web, permettant aux testeurs d’identifier d’éventuels goulets d’étranglement de performance ou d’autres problèmes qui pourraient survenir sous de fortes charges. JMeter peut être utilisé pour mesurer diverses métriques de performance, telles que le temps de réponse, le débit et le taux d’erreur.

JMeter utilise une interface basée sur une interface graphique pour permettre aux utilisateurs de créer des plans de test, qui peuvent inclure plusieurs scénarios de test, chacun avec des paramètres et configurations différents. Les testeurs peuvent également personnaliser JMeter à l’aide de plug-ins ou en écrivant du code personnalisé, ce qui leur permet d’étendre ses fonctionnalités au-delà de ses spécifications de base. Les plugins peuvent nous aider à travailler avec des services qui utilisent des protocoles non HTTP, tels que AMQP et Websocket.

Même si JMeter offre une large gamme de fonctionnalités et de fonctions pour les tests de charge, il se peut que certains cas d’utilisation ou exigences ne soient pas couverts par les fonctionnalités intégrées. En développant des plugins personnalisés, les testeurs peuvent ajouter de nouvelles fonctionnalités ou personnaliser des fonctionnalités existantes pour mieux répondre à leurs besoins.

Par exemple, un plugin personnalisé pourrait être développé pour simuler un type spécifique de comportement utilisateur ou pour générer des données de test plus réalistes. De plus, des plugins personnalisés peuvent être développés pour intégrer JMeter à d’autres outils ou systèmes, tels que des outils de journalisation et de rapport ou des pipelines d’intégration et de déploiement continus. 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. Dans l’ensemble, 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, nous supposons qu’un appareil fait des relevés de la température et de l’humidité sur une période définie. Nous pouvons simuler ce comportement simple en utilisant un plugin personnalisé JMeter. Dans l’implémentation actuelle du plugin personnalisé fourni ici, nous générons des données aléatoires en utilisant un modèle fourni. Cependant, le plugin peut contenir tout comportement complexe possible pour tout 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 Azure Function qui est responsable du traitement des données puis de l’envoi des données à d’autres services en aval tels que la base de données Azure SQL. La Azure Function est le service que nous voulons tester. 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 de tests de charge Azure avec des plugins personnalisés peut être utile dans divers scénarios, tels que :

Tester la performance 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.
Simuler un type spécifique de comportement d’utilisateur ou d’appareil, ou générer des données de test plus réalistes.

Plug-ins personnalisés

Les plugins personnalisés dans le contexte de JMeter sont des composants logiciels qui peuvent être ajoutés à JMeter pour étendre sa fonctionnalité au-delà de ce qui est fourni par défaut. Les utilisateurs ou les développeurs non Microsoft peuvent développer des plugins personnalisés pour ajouter de nouvelles fonctionnalités, fonctions ou intégrations à JMeter. Les plugins personnalisés peuvent être développés en utilisant le langage de programmation Java et le JMeter Plugin Development Kit (PDK). Le PDK fournit un ensemble d’outils et d’API qui facilitent la création de nouveaux plugins dont des éléments d’interface utilisateur, des écouteurs et des échantillonneurs.

Les plugins personnalisés peuvent ajouter une large gamme de fonctionnalités à JMeter. Ils peuvent également intégrer JMeter à d’autres systèmes, tels que des outils de journalisation et de rapport, ou permettre l’utilisation d’autres sources de données pour les données de test. Dans l’ensemble, les plugins personnalisés permettent aux utilisateurs d’étendre JMeter pour répondre à leurs besoins spécifiques et d’améliorer la précision et l’efficacité de leurs efforts de test de charge.

Pour mettre en œuvre un échantillonneur personnalisé pour Event Hubs dans JMeter, veuillez suivre les instructions fournies dans Plugins de tests de charge Azure. Une fois votre échantillonneur personnalisé implémenté, vous pouvez l’utiliser dans votre plan de test JMeter dans le test de charge Azure comme tout autre échantillonneur.

Un plan de test peut être implémenté à l’aide d’un groupe de threads qui contrôle le nombre de threads (utilisateurs et appareils virtuels) 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 être exécutés séquentiellement ou en parallèle, selon la configuration du plan de test et les 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, vous permettant de simuler des scénarios et des demandes complexes que les échantillonneurs intégrés ne prennent pas en charge.

Créez un script Apache JMeter avec plugin 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 sur votre machine locale :
```
touch LoadTest.jmx
```

Ouvrez LoadTest.jmx dans un éditeur de texte et collez le morceau 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 et prend 10 minutes à compléter :

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

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

Dans le fichier, donnez pour valeur au nœud eventHubConnectionVarName le nom de variable qui spécifie l’hôte de la chaîne de connexion Event Hubs. Par exemple, si vous voulez que la variable d’environnement qui stocke la chaîne de connexion de Event Hubs soit EventHubConnectionString, paramétrez cette variable sur EventHubConnectionString puis définissez la valeur de la variable environnementale.

Important

Assurez-vous que la valeur de EventHubConnectionString a été définie dans le cadre du processus de création de test de charge Azure avant d’exécuter le script de test de charge.
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 contenant 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 pour le message du hub d’événements est un objet JSON avec trois propriétés, dont MachineId, Temperature et Humidity, où MachineId est un identifiant généré aléatoirement avec une longueur de 27, 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 modélisation populaire utilisé dans divers cadres 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. Dans l’ensemble, les modèles liquides offrent un moyen puissant et flexible de créer des messages dynamiques et personnalisables.
Enregistrez le fichier et fermez-le.

Important

N’incluez aucune donnée personnelle dans le nom de l’échantillonneur dans le script JMeter. Les noms des échantillonneurs apparaissent dans le tableau de bord des résultats des tests de charge Azure. Un exemple de modèle Liquid ainsi que le fichier de script JMeter peuvent être téléchargés dans Azure Samples.

Exécutez le test de charge avec le nouveau plugin

Lorsque votre test de charge Azure démarre, il déploie d’abord le script JMeter ainsi que tous les autres fichiers sur les instances du moteur de test, puis il démarre le test de charge comme indiqué dans Personnaliser un test de charge avec des plugins Apache JMeter et le test de charge Azure. Avant de lancer le test, rendez-vous dans l’onglet des paramètres, définissez EventHubConnectionString, puis fournissez la chaîne de connexion au hub d’événements.

Configuration du test de performance pour l’environnement

Dans tout test de performance, il est important d’avoir un environnement similaire à l’environnement de production. Dans cet exemple, l’environnement suivant est utilisé pour les tests de performance afin de mieux comprendre la capacité du système et sa performance :

Selon l’architecture d’échantillon, les services suivants peuvent être utilisés pour les tests de performance :

Service	Configuration
Event Hubs	Premium avec une Unité de Traitement (PU).
Fonction Azure	Linux avec Plan Premium (EP1) - 210 ACU, 3,5 Go de mémoire et 1 vCPU équivalent à Standard_D1_v2.
Région	USA Est

Choisir le bon niveau de service pour tout service Azure, Event Hubs et Azure Functions inclus, est un processus complexe et dépend de nombreux facteurs. Pour plus d’informations, veuillez consulter la tarification d’Azure Event Hubs et la tarification d’Azure Functions.

Conception des KPI pour les tests de performance

Avant de pouvoir concevoir des Indicateurs Clés de Performance (KPI) pour les tests de performance, il est nécessaire de définir à la fois les exigences commerciales et l’architecture du système. Les exigences commerciales vous indiquent quels KPI mesurer, tels que le temps de réponse, le débit ou le taux d’erreur. 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.

Dans cet exemple, les exigences commerciales sont les suivantes :

Le système doit être capable de gérer 1 000 requêtes par seconde.
La fiabilité du système doit être supérieure à 0,99.
Le système doit être capable de gérer 1 000 appareils concurrents rapportant leurs informations personnelles.
Spécifier la capacité maximale du système en termes de nombre d’appareils pouvant être pris en charge. Par exemple, le système avec 3 fois la capacité actuelle peut-il supporter 1 000 appareils simultanés ?

Selon ces exigences, les KPI pour les tests de performance pourraient être :

Indicateur de performance clé	Description
RPS	Requêtes Par Seconde pour un hub d’événements
LOAD	Nombre de charges ou de requêtes envoyées au hub d’événements pendant les tests de performance
IR	Nombre d’exécutions de fonctions ou taux d’ingestion
RT	Temps moyen pour l’exécution de la fonction Azure
AMU	Utilisation moyenne de la mémoire pour les fonctions Azure
SR	Taux de réussite de toutes les exécutions de fonctions
ARS	Temps de réponse moyen du service en aval (par exemple, serveur SQL ou microservice)
DF	Nombre d’échecs de dépendance, incluant les erreurs internes de la fonction Azure
MRPS	RPS maximal sans Backlog dans le hub d’événements (Capacité du système)

Comment mesurer les KPI

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. Dans cet exemple, la stratégie de test de performance suivante est utilisée :

Event Hubs : L’approche de test de performance pour le hub d’événements consiste à envoyer de nombreux messages au hub d’événements, puis à mesurer le RPS et la CHARGE. 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. Le service Azure Load Testing peut mesurer le RPS et la CHARGE.
Azure Functions : L’approche de test de performance pour Azure Functions consiste à mesurer les métriques suivantes :
- L’IR est le nombre d’exécutions de fonctions ou le taux d’ingestion.
- Le RT est le temps moyen d’exécution de la fonction Azure.
- L’AMU est l’utilisation moyenne de la mémoire pour les fonctions Azure.
- Le SR est le taux de réussite de toutes les exécutions de fonctions.
- L’ARS est le temps de réponse moyen du service en aval.
- Le DF est le nombre d’échecs de dépendance, incluant les erreurs internes de la fonction Azure.
- Le service Azure Monitor peut mesurer l’AMU, l’ARS et le DF, mais pas l’IR, le RT ou le SR.

Pour mesurer les KPI à l’aide du service Azure Monitor, nous devons activer Application Insights pour Azure Functions. Pour plus d’informations, veuillez consulter la section Activer l’intégration d’Application Insights.

Après avoir activé le service Azure Monitor, vous pouvez utiliser les requêtes suivantes pour mesurer les KPI :

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

Voici un exemple de tableau de bord Azure Monitor qui montre les KPI pour Azure Functions basés sur les requêtes :

Conclusion

Dans cet article, vous avez appris à concevoir des KPI et à développer un tableau de bord pour les tests de charge Azure. 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 d’intégration et de livraison continue (CI/CD) pour vos scripts de test de charge à l’aide d’Azure DevOps.

Pour plus d’informations, veuillez consulter la page Tests de charge Azure.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Mahdi Setayesh | Ingénieur logiciel principal

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

Test de charge Azure avec des plug-ins personnalisés

Architecture

Dataflow

Composants

Détails du scénario

Cas d’usage potentiels

Plug-ins personnalisés

Créez un script Apache JMeter avec plugin personnalisé

Exécutez le test de charge avec le nouveau plugin

Configuration du test de performance pour l’environnement

Conception des KPI pour les tests de performance

Comment mesurer les KPI

Exemple de tableau de bord Azure Monitor

Conclusion

Contributeurs

Étapes suivantes

Commentaires

Commentaires

Ressources supplémentaires

Test de charge Azure avec des plug-ins personnalisés

Architecture

Dataflow

Composants

Détails du scénario

Cas d’usage potentiels

Plug-ins personnalisés

Créez un script Apache JMeter avec plugin personnalisé

Exécutez le test de charge avec le nouveau plugin

Configuration du test de performance pour l’environnement

Conception des KPI pour les tests de performance

Comment mesurer les KPI

Exemple de tableau de bord Azure Monitor

Conclusion

Contributeurs

Étapes suivantes

Ressources associées

Commentaires

Commentaires

Ressources supplémentaires