Articles avec le tag ‘jprofiler’

Les tests de charge à caractère technique (robustesse) sont ils importants ?

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 dit 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 noeud.

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

Bon vous ne me laisser 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 😉

Lire la suite de cette entrée »

Optimiser une application JEE : mesurer l’impact sur un cas pratique (3ème partie)

3ème partie de notre saga performance.

Lors de notre dernier article, nous avons pu "faire sauter les verrous" en augmentant le pool de threads qui nous limitait le nombre de traitements simultanés dans la montée en charge. Attardons nous maintenant sur la JVM.

Nous n'allons pas perdre de temps dans le fonctionnement d'une JVM plusieurs articles sauront vous le rappeler très simplement comme le chapitre 3 de cet article qui traite de l'overhead, ou bien celui plus spécifique du fonctionnement de la JVM d'IBM J9.

Partant de cela, allons voir un peu comment la notre préfigure ...

Commençons par activer le port JMX sur notre serveur Glassfish pour introspecter avec un outil de monitoring (plusieurs existent comme JConsole inclue dans le J2SE, VisualVM ...).

Lire la suite de cette entrée »

Mots-clés
RSS Feed