Saturation du générateur de charge
Saturation du générateur de charge
La charge est elle aussi produite par des machines. Si un moteur de génération passe l'exécution près de 100 % de CPU, il ne peut pas envoyer les requêtes au rythme configuré, et les temps de réponse qu'il enregistre incluent l'attente de son propre CPU. Les chiffres décrivent alors le générateur, pas votre application.
La vue d'ensemble affiche une bannière d'alerte lorsqu'un moteur a atteint 80 % de CPU ou plus pendant l'exécution, en nommant le moteur et son pic. Les séries complètes CPU, mémoire, réseau et disque sont dans l'onglet Engine Health.
Le reconnaître dans les résultats
- Le temps de réponse grimpe avec le nombre d'utilisateurs virtuels, mais la supervision de la cible la montre inactive.
- Le débit plafonne alors que le taux d'erreur reste nul.
- Un emplacement est plus lent que les autres, et c'est celui dont le moteur était saturé.
Considérez chaque temps de réponse d'une exécution saturée comme une borne inférieure : la vraie valeur est au mieux celle-là.
Corriger le test
- Répartissez le même nombre d'utilisateurs sur davantage de moteurs ou d'emplacements, pour que chaque moteur travaille moins.
- Retirez du script le travail coûteux par requête : gros extracteurs d'expressions régulières, parsing JSON de corps volumineux, journalisation par requête.
- Réduisez le nombre d'utilisateurs par moteur et allongez la montée en charge plutôt que de tout démarrer d'un coup.
- Relancez et vérifiez que la bannière a disparu avant de vous fier au graphique temps de réponse vs utilisateurs virtuels.
Voir aussi matériel et infrastructure des générateurs de charge.