Archive pour la catégorie ‘Architectures J2EE’

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 »

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 »

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 »

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 »

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

Depuis un certain temps, on vous propose plusieurs articles allant d'une démo avancée d'un outil de performance, jusqu'à des mises en situation poussant l'analyse de fuites mémoires dans ses retranchements.

Nous allons vous proposer un cas pratique, décrivant une intervention d'audit de performance, l'histoire d'une application critique pour laquelle on déplore de gros problèmes de performances.

Partant de ce postula, nous allons tenter de vous proposer une approche méthodique par laquelle nous aborderons chaque étape comme des étapes significatives dans l'augmentation de gains en performance.

Lire la suite de cette entrée »

OutOfMemoryError Java, que faire ?

Introduction

Un des atouts (ou inconvénient pour certains) de Java est qu'il n'y a pas à s'occuper de la libération de la mémoire grâce au Ramasse Miettes (Garbage Collector).

Malgré cela, nous ne sommes pas à l’abri de fuites mémoires (la fameuse exception OutOfMemoryError).

Pour pallier à ce problème, le moyen le plus simple est de faire un arrêt/relance de l'application. Solution que je déconseille d'utiliser, car en plus du problème de performance, s'ajoute le problème de disponibilité de l'application pour les clients.

Plus globalement, sans vouloir être puriste, nous n'avons pas d'autres choix que de corriger l’OutOfMemoryError, que cela soit un mauvais paramétrage de la JVM et/ou une fuite mémoire.

L'objectif de cet article est de comprendre comment apparaissent les OutOfMemoryError.
Lire la suite de cette entrée »

Pourquoi faut-il faire attention au nombre d’index SQL

1 - Introduction

Une solution simple pour augmenter les performances au niveau base de données est de maîtriser la gestion des index. Vous avez sûrement lu ou déjà expérimenté l'impact de l'ajout d'un index sur les performances d'une requête.

Malheureusement, il faut bien être sensibilisé sur le nombre d'index sur une table car ils ont un coût, et en particulier pour les opérations UPDATE, DELETE et INSERT INTO.

Afin de démontrer ce coût, nous allons utiliser le « couteau suisse » de JMeter associé à Benerator.
Lire la suite de cette entrée »

Découvrir et isoler une fuite mémoire java – part 2

2. Le contexte

Comme décrit de manière rapide sur la 1ère partie du post,   je me retrouve donc confronté à un problème clairement identifié comme fuite mémoire chez l'un de nos clients.

Les outils de supervision des JVM des équipes d'exploitation remontant une consommation anormale de la Heap avec surtout des impacts très limitées du GC en terme de libération de mémoire (malgré un nombre important de FullGC).


Lire la suite de cette entrée »

Mots-clés
RSS Feed