L'agent Application Real-Time Monitoring Service (ARMS) instrumente les bytecodes lors de l'exécution de l'application pour en gérer les performances. Comme toute solution de gestion des performances basée sur l'instrumentation des bytecodes, l'agent ARMS pour Java engendre une certaine surcharge. Toutefois, l'équipe ARMS a mis en œuvre plusieurs techniques pour réduire cette surcharge sans compromettre la stabilité de l'application. Ce rapport simule différents scénarios de trafic afin d'évaluer la surcharge de l'agent ARMS pour Java V4.x. Avant de connecter votre application à Application Monitoring, nous vous recommandons de consulter ce rapport pour réaliser une évaluation complète.
Scénarios de test
Organigramme
Développée selon le modèle Spring Web MVC (Model-View-Controller), l'application Java accède à MySQL et Redis via les frameworks Druid et Jedis, en fonction des requêtes envoyées par Alibaba Cloud Performance Testing (PTS).
Lorsqu'elle reçoit les requêtes
${mall-gateway}/case/api/v1/mysql/execute, l'application accède à MySQL. Pour chaque requête reçue, l'application effectue entre 1 et 4 accès à MySQL.Lorsqu'elle reçoit les requêtes
${mall-gateway}/case/api/v1/redis/execute, l'application accède à Redis. Pour chaque requête reçue, l'application effectue entre 1 et 10 accès à Redis.
Environnement de test
La source du test de charge est fournie par PTS.
L'application Java, MySQL et Redis sont déployés dans le même cluster Container Service for Kubernetes (ACK) d'Alibaba Cloud. Le type d'instance des nœuds est ecs.u1-c1m2,8xlarge et leur système d'exploitation est Alibaba Cloud Linux 2.1903 LTS 64 bits.
-
Chaque pod de l'application dispose de 2 cœurs, de 4 Go de mémoire et de deux réplicas. Les paramètres JVM sont les suivants :
-Xms3500m -Xmx3500m -XX:MetaspaceSize=500m La version de l'agent ARMS pour Java est la 4.2.1.
Procédure de test
Effectuez trois tests de charge à 500, 1 000 et 2 000 QPS. Chaque test dure 1 heure. Avant chaque test, préchauffez l'application Java à 100 QPS pendant 3 minutes. Les résultats serviront de référence pour les métriques de performance de base.
Installez l'agent ARMS pour Java V4.1.11. Configurez un taux d'échantillonnage de 10 % dans la politique d'échantillonnage, puis répétez les tests de charge de l'étape 1 pour comparer les différences de consommation CPU, de consommation mémoire et de temps de réponse de l'application Java.
Installez l'agent ARMS pour Java V4.1.11. Configurez un taux d'échantillonnage de 100 % dans la politique d'échantillonnage, puis répétez les tests de charge de l'étape 1 pour comparer les différences de consommation CPU, de consommation mémoire et de temps de réponse de l'application Java.
Pour plus d'informations sur la configuration de la politique d'échantillonnage, reportez-vous à Modes d'échantillonnage des traces (Agent V3.2.8 ou version ultérieure).
Les fonctionnalités de base d'Application Monitoring sont activées, notamment les métriques, les traces et les quantiles. Tous les plug-ins sont également activés. Certaines fonctionnalités avancées sont temporairement désactivées, telles que la compression des traces, la convergence des URL, le masquage des données et le profilage continu.
Métriques de performance de base
|
Élément |
CPU |
Mémoire |
Temps de réponse (unité : millisecondes) |
|
500 QPS |
6 737 % |
11,51 % |
57,6 |
|
1 000 QPS |
13 040 % |
11,81 % |
63,9 |
|
2 000 QPS |
26,796 % |
12,19 % |
70,5 |
La métrique CPU représente le pourcentage d'utilisation du CPU par les pods par rapport au CPU total (2 cœurs).
La métrique mémoire représente le pourcentage d'utilisation de la mémoire par les pods par rapport à la mémoire totale. Étant donné que la mémoire utilisée par les pods augmente naturellement jusqu'à atteindre la valeur demandée, le rapport utilise l'utilisation réelle de la mémoire à la fin des tests de charge.
La métrique de temps de réponse représente le temps de réponse moyen des requêtes. Unité : millisecondes.
Métriques de performance de l'agent ARMS pour Java V4.x
|
Élément |
Taux d'échantillonnage de 10 % |
Taux d'échantillonnage de 100 % |
||||
|
CPU |
Mémoire |
Temps de réponse (unité : millisecondes) |
CPU |
Mémoire |
Temps de réponse (unité : millisecondes) |
|
|
500 QPS |
8,412 % |
13,72 % |
58,5 |
9,316 % |
13,91 % |
58,7 |
|
1 000 QPS |
16,947 % |
14,14 % |
64,9 |
18,114 % |
14,42 % |
65,3 |
|
2 000 QPS |
34,850 % |
14,64 % |
74,6 |
35,945 % |
14,67 % |
76,1 |
La relation entre le taux d'échantillonnage, le CPU et les QPS n'est pas linéaire. Par défaut, il existe une limite supérieure pour la collecte de traces par seconde.
Surcharge de performance de l'agent ARMS pour Java V4.x
|
Élément |
Taux d'échantillonnage de 10 % |
Taux d'échantillonnage de 100 % |
||||
|
CPU |
Mémoire |
Temps de réponse (unité : millisecondes) |
CPU |
Mémoire |
Temps de réponse (unité : millisecondes) |
|
|
500 QPS |
+1,68 % |
+2,21 % |
+0,9 |
+2,58 % |
+2,40 % |
+1,1 |
|
1 000 QPS |
+3,907 % |
+2,33 % |
+1,0 |
+5,07 % |
+2,61 % |
+1,4 |
|
2 000 QPS |
+8,05 % |
+2,45 % |
+4,1 |
+9,14 % |
+2,48 % |
+5,6 |
Conclusion
La surcharge supplémentaire en CPU et en mémoire causée par l'agent ARMS pour Java V4.x reste inférieure à 10 %.
L'agent ARMS pour Java V4.x a un impact faible sur le temps de réponse (10 %), qui n'augmente que de 1 milliseconde à 1 000 QPS.
La surcharge de performance avec un taux d'échantillonnage fixe de 100 % est légèrement supérieure à celle observée avec un taux fixe de 10 %.