Antoniogomesrodrigues Importancetestsdechargetechnique

Tutoriel pour comprendre pourquoi les
tests de charge caractre technique

(robustesse) sont-ils importants ?
Par Antonio Gomes-Rodrigues
Date de publication : 13 dcembre 2016
Votre application a russi tous les tests, qu'ils soient unitaires, d'intgration, fonctionnels ou
de charge et nous voil enfin prts la mettre en production.
Mais vous vous posez toujours des questions sur comment va ragir votre application
en cas de fonctionnement dgrad. Dans ces cas-l, les tests de robustesse sont-ils
importants ? Ce tutoriel rvle l'importance des tests de robustesse dans la dtermination
du comportement d'une application en cas de fonctionnement dgrad.
Pour ragir ce support de cours, un espace de dialogue vous est propos sur le forum
Commentez.
Tutoriel pour comprendre pourquoi les tests de charge caractre technique (robustesse) sont-ils importants ? par Antonio Gomes-Rodrigues
I - Introduction..............................................................................................................................................................3
II - Une preuve.............................................................................................................................................................3
III - Conclusion...........................................................................................................................................................11
IV - Remerciements................................................................................................................................................... 12
-2Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge
par les droits d'auteur. Copyright 2016 Antonio Gomes-Rodrigues. Aucune reproduction, mme partielle, ne peut tre faite de ce site et de l'ensemble de son contenu : textes, documents,
images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu' trois ans de prison et jusqu' 300 000 de dommages et intrts.
http://arodrigues.developpez.com/tutoriels/java/tests-robustesse-jmeter/
I - Introduction
Mettons-nous d'abord d'accord sur la dfinition de tests de charge caractre technique (ou test de
robustesse) .
Il s'agit de tester un systme en mode dgrad : ralentissement de l'application, un des serveurs est non disponible,
rseau satur, panne mmoire, disque plein, rseau dfaillant, etc. sous forte charge.
Maintenant que nous sommes d'accord, commenons.
Votre application a russi tous les tests, qu'ils soient unitaires, d'intgration, fonctionnels ou de charge et nous voil
enfin prts la mettre en production.
Mais vous vous posez toujours des questions sur comment va ragir votre application en cas de fonctionnement
dgrad.
Les dlais font que l'application est mise en production sans la ralisation de ces tests.
Deux jours plus tard, aprs une campagne de publicit qui vous a apport beaucoup de nouveaux utilisateurs, on
vous rveille deux heures du matin pour que vous veniez d'urgence au bureau, car l'application est dans
un tat instable.
Dommage, car des tests de robustesse auraient srement pu vous viter ce dsagrment.
Vous ne me croyez pas, vous avez raison.
Et si je vous dis que lors de mes missions, j'ai rencontr :
des crashs de l'application cause d'un consommateur JMS non dmarr ;

des crashs de l'application cause d'un load balancer mal configur ;
des problmes de rpartition de charge dans un cluster d'Apache ActiveMQ aprs l'arrt/relance d'un nud.
Toujours pas. Et si je vous dis que ces problmes sont arrivs dans de grosses structures sur des projets plus ou
moins gros et avec des gens comptents ?
Bon, vous ne me laissez plus le choix, nous allons voir un exemple qui vous prouvera (enfin je l'espre) l'importance
de ces types de tests.
Mais avant cela, comment allez-vous reproduire ce bug qui est arriv en environnement de production sur votre
environnement de test ?
Avec un test de robustesse bien sr.
II - Une preuve
Notre application est la fameuse Spring PetClinic.
Pour simuler la charge, nous allons utiliser Apache JMeter.
Notre script ralisera les actions suivantes :
Aller sur la page d'accueil :
Aller sur la page de recherche :
Excuter une recherche :
Notre script aura la forme suivante :
Maintenant, nous voulons savoir : Que se passe-t-il si votre fonctionnalit de recherche

(module critique de votre applicatif) met plus de huit secondes rpondre ?
Pour simuler ce ralentissement, nous allons utiliser JBoss Byteman qui se prsente sous la forme d'un agent Java
capable de modifier le comportement de notre application en instrumentant son bytecode.
Les avantages de JBoss Byteman sont nombreux :
on peut dclencher ce que l'on veut (ralentissement de l'application, perte de connexion la base de
donnes, disque plein, etc.) lorsqu'on veut (il suffit d'uploader les rgles Byteman sur l'application cible) ;
on peut simuler des choses difficilement testables avec un test de charge (ralentissement d'une partie de
l'application, disque dur plein, avoir un problme de connexion la base une fois sur cinq, etc.) ;
le tout sans intervention extrieure (pas besoin de l'quipe d'exploitation pour arrter la base de donnes, il
suffit d'avoir le mme compte pour le lancement de Byteman et de l'application).
Ajoutons Byteman notre script (connexion de Byteman la JVM, chargement des rgles de modification du
comportement de l'application dix minutes aprs le dbut du test, suppression de ces mmes rgles vingt minutes
aprs le dbut du test).
Avec ce script, Apache JMeter s'occupera de tout (simulation des utilisateurs, de la charge
et du lancement de JBoss Byteman).
Lanons notre test avec une charge faible.
On voit bien l'impact sur les temps de rponse.

ce moment-l, on peut se dire : c'est dommage pour les utilisateurs, mais a pourrait tre pire .
Excutons le test nouveau, mais avec une charge plus leve et regardons plus en dtail cette fois-ci.
Changement de comportement, les temps de rponse ne reviennent pas la normale aprs la suppression des
rgles de modification du comportement de l'application.
Si on regarde le nombre de requtes traites par notre application, on remarque une baisse importante de celui-ci
(et adieu notre prime indexe sur les ventes ralises dans le cas d'un site de e-commerce).
Et comme pour les temps de rponse, elles ne reviennent pas la normale.

Afin de comprendre ce comportement, nous allons utiliser JProfiler qui va nous faciliter l'analyse de notre application.
On remarque que la mmoire de notre application est moins stresse (moins de passage du GarbageCollector).
Ce qui est normal, car notre application traite moins de requtes.

La contention ne venant pas de la gestion de la mmoire, on regarde du ct des threads.
Bingo, on remarque :
qu'un ou plusieurs threads sont bloqus partir du chargement des rgles Byteman ;
que les threads rpondant aux requtes HTTP (en bleu) sont utiliss de manire chaotique lorsque les
rgles Byteman sont actives (encadr en rouge) ;
que l'utilisation des threads rpondant aux requtes HTTP (en bleu) atteint un plafond aprs la suppression
des rgles Byteman.
Le Thread Views de JProfiler nous confirme bien nos remarques.
Ici l'utilisation chaotique (beaucoup plus de threads en pause sur la partie encadre en rouge) puis l'atteinte du
plafond (plus aucun thread en pause).
Et ici la saturation du thread qui accepte les connexions HTTP.
- 10 Les sources prsentes sur cette page sont libres de droits et vous pouvez les utiliser votre convenance. Par contre, la page de prsentation constitue une uvre intellectuelle protge
On en dduit que l'on a satur notre pool de threads (paramtr dix afin de faciliter la lecture
des captures d'cran et notre analyse) et que l'application n'arrive plus sortir la tte de
l'eau .
Et en voil la preuve.
On vient de voir l'effet boule de neige (blocage de notre application) provoqu par le ralentissement d'une partie de
cette mme application.
Plusieurs solutions existent pour corriger ce problme :
optimisation du code (solution court terme, car la probabilit que le problme arrive en production ne sera
jamais nulle) ;
tuning d'Apache Tomcat ;
duplication de votre module de recherche sur le mme serveur (Vertical Scaling) ;
duplication de votre module de recherche sur d'autres serveurs (Horizontal Scaling) ;
changement de technologie pour votre module de recherche (par exemple ElasticSearch).
III - Conclusion
Ma rponse la question Les tests de charge caractre technique (robustesse) sont-ils importants ? est oui.
Mes conseils sont :
de faire des tests de charge caractre technique en plus des tests de charge ;
si possible les automatiser (dans cet exemple avec Apache JMeter et JBoss Byteman) ;
de bien vous outiller (ici JProfiler) ;
ces tests ne sont qu'une simulation et donc de bien superviser l'environnement de production (par exemple
avec AppDynamics, Nagios).
IV - Remerciements
Les remerciements vont Antonio Gomes-Rodrigues pour le partage de ce tutoriel avec les lecteurs de
Developpez.com.
Nous tenons remercier f-leb pour la relecture orthographique attentive de cet article et Mickael BARON pour la
mise au gabarit.

Antoniogomesrodrigues Importancetestsdechargetechnique

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Antoniogomesrodrigues Importancetestsdechargetechnique

Загружено:

Авторское право:

Доступные форматы

Tutoriel pour comprendre pourquoi les

tests de charge caractre technique

des crashs de l'application cause d'un consommateur JMS non dmarr ;

Aller sur la page d'accueil :

Aller sur la page de recherche :

Excuter une recherche :

Notre script aura la forme suivante :

Maintenant, nous voulons savoir : Que se passe-t-il si votre fonctionnalit de recherche

Lanons notre test avec une charge faible.

On voit bien l'impact sur les temps de rponse.

Et comme pour les temps de rponse, elles ne reviennent pas la normale.

Ce qui est normal, car notre application traite moins de requtes.

Le Thread Views de JProfiler nous confirme bien nos remarques.

Et ici la saturation du thread qui accepte les connexions HTTP.

Вам также может понравиться