Developpez.com

Plus de 2 000 forums
et jusqu'à 5 000 nouveaux messages par jour

Tutoriel pour comprendre pourquoi les tests de charge à caractère technique (robustesse) sont-ils importants ?

Votre application a réussi tous les tests, qu'ils soient unitaires, d'intégration, fonctionnels ou de charge et nous voilà enfin prêts à la mettre en production.
Mais vous vous posez toujours des questions sur comment va réagir votre application en cas de fonctionnement dégradé. Dans ces cas-là, les tests de robustesse sont-ils importants ? Ce tutoriel révèle l'importance des tests de robustesse dans la détermination du comportement d'une application en cas de fonctionnement dégradé.

Pour réagir à ce support de cours, un espace de dialogue vous est proposé sur le forum Commentez Donner une note à l'article (5).

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

Mettons-nous d'abord d'accord sur la définition de « tests de charge à caractère technique (ou test de robustesse) ».
Il s'agit de tester un système en mode dégradé : ralentissement de l'application, un des serveurs est non disponible, réseau saturé, panne mémoire, disque plein, réseau défaillant, etc. sous forte charge.
Maintenant que nous sommes d'accord, commençons.

Votre application a réussi tous les tests, qu'ils soient unitaires, d'intégration, fonctionnels ou de charge et nous voilà enfin prêts à la mettre en production.
Mais vous vous posez toujours des questions sur comment va réagir votre application en cas de fonctionnement dégradé.

Les délais font que l'application est mise en production sans la réalisation de ces tests.
Deux jours plus tard, après une campagne de publicité qui vous a apporté beaucoup de nouveaux utilisateurs, on vous réveille à 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 sûrement pu vous éviter ce désagrément.

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 démarré ;
  • des crashs de l'application à cause d'un load balancer mal configuré ;
  • des problèmes de répartition de charge dans un cluster d'Apache ActiveMQ après l'arrêt/relance d'un nœud.

Toujours pas. Et si je vous dis que ces problèmes sont arrivés dans de grosses structures sur des projets plus ou moins gros et avec des gens compétents ?

Bon, vous ne me laissez plus le choix, nous allons voir un exemple qui vous prouvera (enfin je l'espère) 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 sûr. 

Image non disponible

II. Une preuve

Notre application est la fameuse Spring PetClinic.

Pour simuler la charge, nous allons utiliser Apache JMeter.

Notre script réalisera les actions suivantes :

  • Aller sur la page d'accueil :
    Image non disponible
  • Aller sur la page de recherche :
    Image non disponible
  • Exécuter une recherche :
    Image non disponible
  • Notre script aura la forme suivante :
    Image non disponible

Maintenant, nous voulons savoir : « Que se passe-t-il si votre fonctionnalité de recherche (module critique de votre applicatif) met plus de huit secondes à répondre ? »

Pour simuler ce ralentissement, nous allons utiliser JBoss Byteman qui se présente 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 déclencher ce que l'on veut (ralentissement de l'application, perte de connexion à la base de données, disque plein, etc.) lorsqu'on veut (il suffit d'uploader les règles 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 problème de connexion à la base une fois sur cinq, etc.) ;
  • le tout sans intervention extérieure (pas besoin de l'équipe d'exploitation pour arrêter la base de données, il suffit d'avoir le même compte pour le lancement de Byteman et de l'application).

Ajoutons Byteman à notre script (connexion de Byteman à la JVM, chargement des règles de modification du comportement de l'application dix minutes après le début du test, suppression de ces mêmes règles vingt minutes après le début du test).

Image non disponible

Avec ce script, Apache JMeter s'occupera de tout (simulation des utilisateurs, de la charge et du lancement de JBoss Byteman).

Lançons notre test avec une charge faible.

Image non disponible

On voit bien l'impact sur les temps de réponse.

À ce moment-là, on peut se dire : « c'est dommage pour les utilisateurs, mais ça pourrait être pire ».

Exécutons le test à nouveau, mais avec une charge plus élevée et regardons plus en détail cette fois-ci.

Changement de comportement, les temps de réponse ne reviennent pas à la normale après la suppression des règles de modification du comportement de l'application.

Image non disponible

Si on regarde le nombre de requêtes traitées par notre application, on remarque une baisse importante de celui-ci (et adieu à notre prime indexée sur les ventes réalisées dans le cas d'un site de e-commerce).

Image non disponible

Et comme pour les temps de réponse, 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 mémoire de notre application est moins stressée (moins de passage du GarbageCollector).

Image non disponible
Image non disponible

Ce qui est normal, car notre application traite moins de requêtes.

La contention ne venant pas de la gestion de la mémoire, on regarde du côté des threads.

Bingo, on remarque :

  • qu'un ou plusieurs threads sont bloqués à partir du chargement des règles Byteman ;
  • que les threads répondant aux requêtes HTTP (en bleu) sont utilisés de manière « chaotique » lorsque les règles Byteman sont actives (encadré en rouge) ;
  • que l'utilisation des threads répondant aux requêtes HTTP (en bleu) atteint un plafond après la suppression des règles Byteman.
Image non disponible

Le « Thread Views » de JProfiler nous confirme bien nos remarques.

Ici l'utilisation « chaotique » (beaucoup plus de threads en pause sur la partie encadrée en rouge) puis l'atteinte du plafond (plus aucun thread en pause).

Image non disponible

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

Image non disponible

On en déduit que l'on a saturé notre pool de threads (paramétré à dix afin de faciliter la lecture des captures d'écran et notre analyse) et que l'application n'arrive plus à « sortir la tête de l'eau ».

Et en voilà la preuve.

Image non disponible

On vient de voir l'effet boule de neige (blocage de notre application) provoqué par le ralentissement d'une partie de cette même application.

Plusieurs solutions existent pour corriger ce problème :

  • optimisation du code (solution à court terme, car la probabilité que le problème arrive en production ne sera jamais nulle) ;
  • tuning d'Apache Tomcat ;
  • duplication de votre module de recherche sur le même 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 réponse à la question « Les tests de charge à caractère technique (robustesse) sont-ils importants ? » est oui.

Mes conseils sont :

  • de faire des tests de charge à caractère 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.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2016 Antonio Gomes-Rodrigues. Aucune reproduction, même 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 intérêts.