Définir des bases de référence pour les tests de charge
Maintenant que vous avez défini les tests de charge et les valeurs de seuil, nous allons les utiliser pour créer vos bases de référence.
Une base de référence est un ensemble de critères pour les métriques que vous utilisez afin d’évaluer si un test a échoué ou réussi. Par exemple, vos critères peuvent être les suivants :
- Nombre moyen de requêtes par seconde.
- Taux d’erreur.
- Temps de réponse maximal.
Pour configurer les bases de référence pour les tests de charge, vous devez :
Définir les bases de référence et les critères de test pour les flux d’utilisateurs individuels et la solution globale.
Ajuster les seuils des exécutions régulières pour vérifier que l’application continue à fournir les performances attendues et ne génère aucune erreur.
Utiliser pour les tests de chaos une base de référence distincte qui tolère les pics attendus de taux d’erreur et les baisses de performances temporaires.
Cette activité est continue et doit être conduite régulièrement. Par exemple, vous devez passer en revue les bases de référence après avoir introduit de nouvelles fonctionnalités ou modifié les références SKU de service.
Utiliser Test de charge Azure pour évaluer les seuils
Pendant la phase de développement, les performances des composants et les besoins en ressources ne sont souvent pas clairement connus. Les tests de charge peuvent vous aider à identifier les performances attendues, y compris le comportement de scale-out, de la solution globale et de ses composants. Ils peuvent également vous aider à identifier les seuils à attendre pour la création de votre base de référence.
Posez les questions suivantes et réévaluez régulièrement :
- Combien de temps faut-il pour exécuter une opération, un flux d’utilisateur ou un appel d’API ?
- Combien de requêtes, d’opérations et d’utilisateurs simultanés un composant peut-il servir par seconde ?
- Combien de ressources sont consommées ?
- Comment 10, 50 et 100 utilisateurs simultanés affectent-ils l’infrastructure sous-jacente et le service back-end ?
- Quand faut-il effectuer un scale-in ou un scale-out des composants ?
Les réponses donnent lieu à des tests et des seuils. Les requêtes par seconde, le temps de réponse et le pourcentage d’erreurs sont tous des exemples applicables pour les valeurs de seuil.
Une fois que vous avez noté les détails, utilisez des valeurs pour analyser et évaluer régulièrement les performances de la solution globale et de ses composants. Utilisez également la base de référence pour identifier l’effet des changements et des dérives par rapport aux performances attendues.
Lorsque vous exécutez les tests, vous pouvez avoir des exigences différentes pour des cas d’usage spéciaux, tels qu’un composant défectueux ou un pic de charge. Dans ces cas-là, des taux d’erreurs plus élevés ou un nombre inférieur de requêtes par seconde peuvent être attendus et acceptables. Vous pouvez avoir une base de référence distincte avec des seuils ajustés pour prendre en compte ces cas de figure. Par exemple :
- Scénarios de charge élevée dans lesquels une opération de scale-out est attendue et requise. Il peut y avoir une dégradation temporaire des performances jusqu’à ce que l’opération soit terminée.
- Expériences de chaos, dans le cadre d’un pipeline de validation continue. Un taux d’erreurs plus élevé peut être attendu jusqu’à ce que les mesures de résilience commencent à réparer automatiquement l’application ou à basculer vers une autre région.
Utilisez Test de charge Azure pour évaluer les performances de votre système par rapport aux seuils définis. Le service dispose d’une fonctionnalité intégrée de critères de test. Autrement dit, vous pouvez spécifier les critères qu’un test de charge doit satisfaire.
Vous pouvez utiliser des critères de test pour implémenter différentes bases de référence, comme illustré dans l’exemple de capture d’écran suivant.
Vous pouvez spécifier ces critères de test au format JSON, et utiliser l’API pour les ajouter à votre test de charge. Voici un exemple :
[
{
"passFailMetrics": {
"<guid-1>": {
"clientmetric": "requests_per_sec",
"aggregate": "avg",
"condition": "<",
"value": 1200.0,
"actualValue": 0.0,
"result": null,
"action": "continue"
},
"<guid-2>": {
"clientmetric": "response_time_ms",
"aggregate": "avg",
"condition": ">",
"value": 75.0,
"actualValue": 0.0,
"action": "continue"
},
"<guid-3>": {
"clientmetric": "error",
"aggregate": "percentage",
"condition": ">",
"value": 0.0,
"actualValue": 0.0,
"action": "continue"
}
}
}
]
Un autre aspect important de la validation continue consiste à injecter des tests qui simulent des problèmes réels. Dans la prochaine unité, vous allez découvrir comment ajouter des expériences de chaos à votre processus de validation.