L’application Spring Pet Clinic est un exemple d’application développé par les développeurs Spring Framework pour démontrer les capacités de Spring Boot, Spring MVC et Spring Data Framework. Nous avons entrepris de mener un test de performance sur cette application et de voir si nous pouvons identifier des goulots d’étranglement de performance.
Configuration de l’environnement
Nous avons cloné le référentiel Github officiel de l’application Spring Pet Clinic et suivi les instructions pour créer un fichier JAR. Une fois le fichier JAR prêt, nous avons lancé l’application sur http://localhost:8080.
Nous avons lancé l’application de clinique pour animaux de compagnie dans l’environnement suivant :
- Ubuntu
- OpenJDK 11
- Tomcat 9 intégré
- Base de données HSQL
- Instance AWS EC2 t3a.medium
Chargement de la configuration de test
Pour effectuer cet exercice, nous avons utilisé Redline13, un outil de test de charge cloud. Nous avons décidé d’utiliser RedLine13, car il offre une capacité de test de charge distribuée dans le cloud à un coût très faible. En plus de cela, il faut un script JMX standard comme entrée pour les tests. Le référentiel Github de l’application Spring Petclinic est livré avec un script JMX de test de charge. Cependant, ce script a eu quelques problèmes. Nous avons corrigé ces problèmes dans le script JMX et exécuté les scénarios suivants dans notre test de charge.
- Chargement de la page d’accueil.
- Consultez la liste des vétérinaires et leurs spécialités.
- Voir les informations du propriétaire de l’animal.
- Mettez à jour les informations du propriétaire de l’animal.
- Ajoutez un nouveau propriétaire d’animal au système.
- Afficher les informations relatives à un animal de compagnie.
- Mettre à jour les informations relatives à un animal de compagnie.
- Ajoutez un nouvel animal de compagnie au système.
- Affichez les informations relatives à l’historique des visites d’un animal.
- Ajoutez des informations relatives à une visite à l’historique des visites de l’animal.
- Énumérez tous les propriétaires d’animaux.
- Trouvez des informations sur le propriétaire d’un animal par le nom de famille.
Nous avons effectué le test de charge avec la configuration suivante :
- Durée : 30 minutes
- Nombre de fils : 150/seconde
- Période de montée en puissance : 60 seconde(s)
Résultats de test
Voici le rapport réel des résultats du test Redline13. Nous aimerions souligner quelques métriques intéressantes qui ont été rapportées par l’outil Reline13.
Fig : Résumé du rapport Redline13
Temps de réponse global : Le temps de réponse moyen au 90 centile était de 5,48 secondes, le temps de réponse moyen au 95 centile était de 6,67 secondes et le temps de réponse moyen au 99 centile était de 9,14 secondes. Il s’agit d’un temps de réponse assez faible, en particulier pour une application de type clinique pour animaux de compagnie vanille. La principale raison de ce temps de réponse médiocre pourrait être due au réseau. Notre outil de test de charge Redline13 a été mis en place dans la région AWS W. Virginia, tandis que l’application de clinique pour animaux Spring Boot a été déployée dans la région AWS US-west1 (Californie du Nord). Étant donné que les transactions devaient être effectuées à travers le pays, le temps de réponse aurait pu être dégradé.
Temps de réponse au niveau de la page : Redline13 signalait également le temps de réponse des demandes individuelles au niveau de la page. Le tableau ci-dessous présente des statistiques complètes pour chaque requête exécutée.
Trafic réseau : Pendant tout le test, nous avons envoyé 1,05 Go de données sur le réseau et reçu 6,68 Go de données de l’application Spring Boot Petclinic
L’utilisation du processeur: L’utilisation du processeur de l’agent de charge pour le test a été « fixée » à 97,90 % pendant presque toute la durée. Il semble que nous générions plus de charge à partir de la machine de test de charge. En tant que recommandation générale, il est conseillé de maintenir l’utilisation du processeur de l’agent de charge autour de 70 % à 80 %.
Caractéristiques de performance
Après avoir exécuté le test de charge pendant 30 minutes, nous avons exécuté l’outil yCrash sur l’application de la clinique pour animaux de compagnie. yCrash capture divers artefacts JVM et au niveau du système tels que le journal GC, le thread dump, le heap dump, netstat, vmstat, iostat, top, top -H,… à partir de l’application et les analyse instantanément. L’outil yCrash découvrira les problèmes de performances dans l’application et en signalera la cause première. Vous trouverez ci-dessous quelques-unes des observations intéressantes signalées par l’outil yCrash.
1. Collecte des ordures ménagères
La récupération de place joue un rôle clé en influençant les caractéristiques de performance de l’application. Les performances de collecte des ordures de l’application de la clinique pour animaux de compagnie étaient excellentes. Le débit global de récupération de place de l’application était de 99,378%. Cela signifie que l’application passait 99,378% de son temps à traiter l’activité client et seulement 0,622% de son temps à traiter les activités de collecte des ordures ménagères. Il s’agit d’un excellent débit GC. De même, le temps de pause maximum de l’application était de 50 ms et le temps de pause moyen était de 10,5 ms. Encore une fois, c’est un excellent temps de pause GC.
Fig : KPI de collecte de déchets rapporté par le yCrash
2. Fils
L’outil yCrash a signalé que l’application avait créé 212 threads. Dans ce 90% des threads, c’est-à-dire 190 threads, étaient dans l’état TIMED_WAITING. En gros, ils ne faisaient rien.
Fig : États des threads signalés par le yCrash
Presque tous les threads TIMED_WAITING provenaient du pool de threads du conteneur Tomcat. Étant donné que nous avons capturé le vidage du thread vers la fin du test, cela pourrait expliquer pourquoi la plupart des threads ne font rien.
Le rapport de thread contient plusieurs sections telles que Deadlock, groupes de threads, threads consommant du processeur, graphique de dépendance transitive des threads bloqués, threads qui rencontrent une exception, arborescence d’appels de threads ; il a également peint le flamegraph, montrant la concentration de l’exécution du chemin de code dans une seule vue concise. Ci-dessous la capture d’écran de celui-ci:
Fig : Graphique en flammes montrant la concentration de l’exécution du chemin de code
3. Tas
L’analyse de vidage de tas signalée par l’outil yCrash a indiqué que l’application gaspille 61 % de mémoire en raison d’une programmation inefficace.
Fig: Statistiques de perte de mémoire rapportées par yCrash
Ce rapport sur le gaspillage de mémoire est à peu près cohérent avec nos conclusions précédentes que nous avons publiées il y a près de 2 ans. Les applications modernes ont tendance à gaspiller beaucoup de mémoire en raison de pratiques de programmation inefficaces. L’application de la clinique pour animaux Spring Boot ne fait pas exception à la règle. Vous pouvez vous référer à notre rapport précédent pour voir où toute la mémoire est gaspillée et comment l’éviter. Nous ne voulons pas répéter le même contenu dans cet article.
4. Processus
Parfois, des pannes et une dégradation de votre application peuvent se produire en raison d’applications voisines exécutées sur le même appareil ou sur les conteneurs voisins. Ainsi, le yCrash rapporte la consommation de ressources de toutes les applications voisines.
Fig : Consommation de ressources de tous les processus (image rognée).
De même, l’outil yCrash signale également diverses métriques au niveau de l’appareil telles que le nombre total de processus en cours d’exécution sur l’appareil, leurs états, l’utilisation globale de la mémoire/espace d’échange, 8 types différents d’utilisation du processeur, les métriques de charge moyenne, etc.
Fig : Consommation globale des ressources de l’hôte
5. Stockage
Parfois, des pannes peuvent survenir en cas de manque d’espace disque. L’application écrit sur le disque à des fins de journalisation ou à d’autres fins. L’outil yCrash signale l’utilisation de l’espace de stockage sur l’appareil. Ci-dessous, le rapport yCrash sur le stockage :
Fig : Utilisation du stockage sur l’appareil
Nous exécutions l’application de la clinique Spring Boot Pet sur un EC2 avec un espace disque très limité. Ainsi, le yCrash a signalé des avertissements sur les montages de fichiers qui manquaient d’espace disque.
6. Réseau
L’outil yCrash rapporte également les statistiques au niveau du réseau telles que le nombre total de connexions TCP/IP, les connexions UDP, les connexions par les hôtes, le temps de ping du réseau, les états de connexion TCP/IP (tels que ESTABLISHED, CLOSE_WAIT, etc.). Étant donné que l’application de la clinique pour animaux Spring Boot n’établissait pas beaucoup de connexions réseau, nous n’avons donc observé aucun problème de connectivité réseau.
Fig : Connexions TCP par hôte et leurs états
7. Noyau
Des problèmes de performances ou une instabilité de l’application peuvent également survenir en raison des problèmes du système d’exploitation. Le yCrash signale également le journal du noyau et les paramètres du noyau. S’il y a un problème de réseau, un problème de mémoire ou des problèmes de lecture/écriture, ils seront signalés dans le fichier journal du noyau.
Fig : journaux du noyau signalés par yCrash
Ci-dessus, se trouve la capture d’écran des journaux du noyau rapportés par yCrash. Aucun problème majeur au niveau du noyau n’a été signalé.
Conclusion
À l’exception de 61% de gaspillage de mémoire, aucun autre problème majeur n’a été découvert lors de nos tests. Bien sûr, d’autres problèmes mineurs ont été observés, comme un manque d’espace disque et un pic de temps CPU système. Nous espérons que vous trouverez cet exercice intéressant. Merci d’avoir lu!