Archive pour la catégorie ‘Performance applicative’

Présentation d’AppDynamics

logoappdynamics
Dans le milieu de la performance,  les principes « Ne devinez pas, mesurez », « Diagnose before Cure ! », « Measure, Don't Guess ! » sont de rigueur.

Il existe même un anti pattern nommé « Shot in the dark ».

Tous ces principes nous disent qu’il est important de superviser notre environnement de test lors de la réalisation d’un test de performance. Et pas seulement lors d’un test de performance, car comme tout test, ce n’est qu’une simulation avec ses imperfections (couverture de test incomplète, plate-forme de test non iso prod, etc.) et donc il est important de superviser son environnement de production sous peine de mauvaises surprises.

Pour réaliser cette tâche, de nombreux outils existent comme Nagios, Zabbix, Quest FogLight, Centreon, etc.

Plus particulièrement les APM (Application Performance Monitoring).

Dans le monde Java, les plus connus de nos jours sont Compuware Dynatrace, NewRelic et AppDynamics.

Dans cet article nous allons voir une partie des possibilités offertes par AppDynamics pour la partie Java.

Lire la suite de cette entrée »

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 »

La performance sous VMWare : généralité (article 1/4)

vmwareDe nos jours, il est fréquent de réaliser des tests de performance sur des machines virtuelles (VM).

Souvent, on réalise une campagne de test de performance sans prendre en compte la spécificité de la virtualisation en considérant que finalement la virtualisation est transparente.

Dans certains cas, il est nécessaire d'aller plus loin dans la performance de la virtualisation. Nous allons traiter ce thème en 4 parties:

  1. Généralités
  2. Les optimisations proposées par VMWare
  3. Comment dimensionner une VM
  4. Les métriques spécifiques à la virtualisation à surveiller durant un test de charge

Lire la suite de cette entrée »

Performance des caches avec Ehcache & Terracotta

Introduction aux caches distribués ... avec Terracotta

 

Ehcache_terracottaLe principe d'un cache logiciel est de permettre à une application d'éviter de répéter des appels de méthodes coûteuses (temps d’exécution ou nombre d'appels).

Le cache se déclenche  en stockant les résultats dès les 1er appels, directement en cache mémoire pour une meilleure accession à ces valeurs lors des appels suivants (exemple : un appel en base de données)

Terracotta est un middleware Java de type NAM (Network Attached Memory) répondant entièrement à cette problématique.

Un NAM permet à plusieurs instances de serveurs mis en cluster, d'accéder aux mêmes graphes d'objets au sein d'une mémoire virtuelle partagée.

Terracotta reste ni plus ni moins qu'un système de cache (EhCache) déployé dans un environnement distribué.

Lire la suite de cette entrée »

Middleware scalable : clusteriser Glassfish 3.1 avec failover et load balancing

glassfish_clusteredLes applications d'aujourd'hui obligent les architectes à relever plusieurs défis lors de la conception d'architectures évolutives.

Particulièrement lorsque ces applications doivent être capables d'assurer une haute disponibilité 24/24 tout en absorbant un nombre croissant d'utilisateurs.

C'est pourquoi les études d'architectures évolutives doivent se faire en amont de tout projet.

L'objectif de cette réflexion va être d'anticiper la scalabilité du système (ajout de matériels et de briques logicielles) de façon à gérer la charge croissante d'activité de l'ensemble de nos applicatifs.

Lire la suite de cette entrée »

Oups j’ai oublié d’activer les logs GC

1 - Introduction

Votre application vient enfin d’être mise en production après la phase de test (fonctionnel, etc.). Les tests ont été concluant, vous êtes donc serein.

Trois jours après, une alerte remonte sur la consommation mémoire élevée. Pour résoudre ce problème, vous faites appel à un spécialiste qui vous demande les logs GC.

Malheureusement ils n’ont pas été activés et il n’est pas possible d’arrêter le serveur pour ajouter les paramètres à la JVM (en particulier pour -XX:+PrintGCDetails) qui nous permettraient d’avoir ces fameux logs.
Lire la suite de cette entrée »

JMS Weblogic : concept et performance

OracleWebLogicLe constat est évident : comprendre les principes de l'architecture JMS offerte par Oracle ne se fait pas sans mal.  Choix d'architectures JMS multiples, orientées robustesse et scalabilité.
Un design complet, complexe également ... et qui peut s'avérer problématique si vous ne mettez pas en avant dès le départ vos contraintes de performance : haute disponibilité, QoS, volumétrie, durée de traitement, contexte transactionnel, SLA, TTL ...

J'espère pouvoir vous éclairer avec ce post, en vous proposant une synthèse balayant les principes les plus importants à retenir, avec comme toujours un vernis performance qui agrémente le tout !

Weblogic JMS design :

Présentation1

Lire la suite de cette entrée »

La supervision facile avec JMXTrans, collectd et Graphite

1 - Introduction

jmxUne des étapes d’une campagne de test de charge est de récupérer un certain nombre de métriques.
Plusieurs solutions sont possibles. L’une d’elles dans le monde Java, est d’utiliser JMX pour récupérer un certain nombre de métriques applicatives de la JVM, du serveur d’application, etc.
De nombreux outils permettent de faire cela, et nous allons nous focaliser sur  JMXTrans qui est puissant et simple à installer.
Afin de récupérer les statistiques systèmes (consommation processeur/mémoire, etc.) nous utiliserons collectd.
Enfin, pour afficher l'ensemble de ces métriques, nous utiliserons Graphite.

Lire la suite de cette entrée »

Optimiser une application JEE : mesurer l’impact sur un cas pratique (4ème et dernière partie)

Dernière partie : l'analyse mémoire.

Nous sommes désormais proches de notre objectif d'optimiser notre application pour la rendre robuste à 1000 utilisateurs connectés simultanément.

Notre précédent article faisait état d'une montée linéaire de l'allocation de la Heap malgré un nombre important de Minor GC ne libérant pas suffisamment de mémoire.

A ce stade de l'analyse, ce type de symptômes nous fait penser à une fuite mémoire. Nous allons nous assurer dans cet article du bon fonctionnement de notre mémoire Glassfish.

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