Audit J2EE

Audit des performances d'une application en Java EE
par Antonio Gomes Rodrigues (arodrigues.developpez.com)

Date de publication : 01 octobre 2009 Dernire mise jour : 14 mars 2011
Cet article est une introduction l'audit de performance d'une application en Java/Java EE.
Audit des performances d'une application en Java EE par Antonio Gomes Rodrigues (arodrigues.developpez.com)
I - Introduction..............................................................................................................................................................4 II - Procdure de test.................................................................................................................................................. 4 II-A - Prparation des tests.................................................................................................................................... 5 II-A-1 - Dfinition du type de test..................................................................................................................... 5 II-A-2 - Dfinition des objectifs de performance............................................................................................... 5 II-A-3 - Prparation de la machine cible.......................................................................................................... 6 II-A-4 - Choix des scnarios............................................................................................................................. 6 II-A-5 - Choix des outils....................................................................................................................................6 II-B - Mesure des performances.......................................................................................................................6 II-C - Identifier les problmes........................................................................................................................... 6 II-C-1 - Memory debugger...........................................................................................................................6 II-C-2 - Profiler............................................................................................................................................. 6 II-C-3 - Thread analyseur............................................................................................................................ 6 II-C-4 - Serveur d'application monitoring.....................................................................................................7 II-C-5 - Base de donnes monitoring..........................................................................................................7 II-D - Corriger les problmes............................................................................................................................ 7 II-E - Superviser les serveurs de productions.................................................................................................. 7 III - Mesure des performances...............................................................................................................................7 III-A - Test de charge........................................................................................................................................7 III-A-1 - Prsentation de JMeter..................................................................................................................7 III-A-2 - Construction d'un plan de tests..................................................................................................... 7 III-A-3 - Dvelopper un plan de test........................................................................................................... 8 III-A-3-a - Conception d'un scnario de test..........................................................................................8 III-A-4 - Excuter les tests...........................................................................................................................8 III-A-5 - Analyse des premiers rsultats......................................................................................................8 IV - Identifier et corriger les problmes............................................................................................................... 10 IV-A - Consommation CPU.............................................................................................................................10 IV-B - Consommation mmoire...................................................................................................................... 11 IV-B-1 - Comment marche la mmoire..................................................................................................... 11 IV-B-2 - Fuite de mmoire.........................................................................................................................13 IV-B-2-a - Analyse de fuite de mmoire partir de dump.................................................................. 14 IV-B-3 - Utilisation des chanes de caractres......................................................................................... 15 IV-B-4 - Trop d'objets................................................................................................................................ 18 IV-B-5 - Frameworks de persistance : Hibernate......................................................................................19 IV-B-5-a - Cls primaires auto-incrmentes...................................................................................... 19 IV-B-5-b - Les stratgies de chargement............................................................................................ 19 IV-B-5-c - Recherche multicritre.........................................................................................................20 IV-C - Optimisation de la partie base de donnes.........................................................................................20 IV-C-1 - Pool de connexion JDBC............................................................................................................ 20 IV-C-2 - TableSpace.................................................................................................................................. 21 IV-C-3 - Gnration des statistiques......................................................................................................... 22 IV-C-4 - Dtecter les requtes coteuses.................................................................................................22 IV-C-4-a - Plan d'excution d'une requte...........................................................................................22 IV-C-4-b - Index....................................................................................................................................24 IV-C-4-c - Dlais d'attente....................................................................................................................24 IV-C-4-d - Optimisation des requtes SQL..........................................................................................25 IV-C-5 - Utilisation de JDBC..................................................................................................................... 25 IV-C-6 - Frameworks de persistance : Hibernate......................................................................................27 IV-D - Performance d'affichage d'une page Web........................................................................................... 27 IV-D-1 - Tuning du serveur d'application pour les JSP.............................................................................28 IV-E - Problmes de thread............................................................................................................................29 IV-E-1 - Pool de Thread............................................................................................................................ 30 IV-E-2 - Serveur web.................................................................................................................................31 IV-E-3 - JVM.............................................................................................................................................. 32 IV-E-4 - Niveau programme...................................................................................................................... 33 IV-E-4-a - Blocs synchroniss..............................................................................................................33 IV-E-4-b - Objets non synchroniss.....................................................................................................33 IV-F - Exception.............................................................................................................................................. 33
-2Copyright 2011 - Gomes Rodrigues Antonio. 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' 3 ans de prison et jusqu' 300 000 E de dommages et intrts. Droits de diffusion permanents accords developpez LLC.
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/
IV-G - Utilisation de cache..............................................................................................................................34 IV-H - flux d'entres/sorties............................................................................................................................ 34 V - Quelques astuces...........................................................................................................................................34 V-A - Copie de tableau...................................................................................................................................34 V-B - Utiliser la dernire JVM si possible...................................................................................................... 34 VI - Conclusion..................................................................................................................................................... 35 VII - Remerciements.............................................................................................................................................35 VIII - Rfrences.................................................................................................................................................. 35
I - Introduction
Malgr l'augmentation de la puissance des machines, il arrive que les objectifs de performance d'une application J2EE ne soient pas atteints. Pour cela il faut mettre en place une politique d'analyse de performance. Cette politique doit tre considre toutes les tapes du projet (et le plus tt possible) et par tous les acteurs du projet. L'architecte doit faire une architecture volutive, le dveloppeur doit crer le code le plus propre possible afin que l'optimiseur soit le plus pertinent, ce code doit bien sr tre test... Mais il faut faire attention ne pas vouloir tout optimiser et se concentrer seulement sur le code source. Une bonne devise serait "Ne devinez pas, mesurez". Nous allons voir dans cet article comment mesurer les performances et corriger les problmes trouvs. Pour cela nous dfinirons une dmarche que nous outillerons. Dans cette dmarche nous apprendrons : faire un test de charge afin d'observer les comportements (consommation de ressources, temps de rponse...) de l'application et son volution en fonction de diffrents paramtres (nombre d'utilisateurs simultans, temps de pause entre chaque action (thinktime)...); mettre en place un profileur sur le code afin de cerner de manire prcise les problmes; analyser les rsultats; corriger ces problmes.
Comme vous le verrez, la mesure des performances et la correction demandent de vastes connaissances et donc il est utile de collaborer avec des spcialistes, en particulier les administrateurs de serveurs d'applications et les administrateurs de bases de donnes (DBA). Dernire chose importante, il faut se mfier des "Performance Tips" qui dpendent du contexte d'utilisation, par exemple une solution peut fonctionner dans un cas et s'avrer catastrophique dans une autre situation ou avec les versions suivantes des composants utiliss (JVM, base de donnes...).
II - Procdure de test
On va utiliser la mthode suivante :
II-A - Prparation des tests

La dfinition des objectifs est une tape importante et doit faire intervenir un certain nombre de personnes du projet. Plus d'informations sur mon article "Crer des plans de tests de charge ralistes"
II-A-1 - Dfinition du type de test

La premire chose dfinir est le type de test que l'on veut faire. Plus d'informations ici.
II-A-2 - Dfinition des objectifs de performance

Plus d'informations ici.
II-A-3 - Prparation de la machine cible

II-A-4 - Choix des scnarios

II-A-5 - Choix des outils

Il est important de choisir des outils que l'on matrise. Plus d'informations ici.
II-B - Mesure des performances

Dans cette partie, on utilisera des outils de test de charge (HP LoadRunner, Apache Jmeter...) pour simuler l'application. Jmeter sera utilis pour la suite. Il peut tre judicieux d'utiliser des outils de supervision mtiers de la performance (Introscope, Dynatrace ).
II-C - Identifier les problmes

Encore une fois, un certain nombre d'outils existent. Cela va des outils intgrs la JDK des outils cotant trs cher en passant par les outils intgrs aux IDE (Netbeans, Eclipse...). Voil les catgories des outils que nous utiliserons
II-C-1 - Memory debugger

Cela nous permettra de : trouver les fuites de mmoire; rduire la consommation de la mmoire; identifier rapidement les mthodes qui crent les objets.
Par exemple avec Yourkit Java Profiler.
II-C-2 - Profiler
Cela nous permettra de : dcouvrir les goulots d'tranglement; avoir des mesures par ligne d'instruction.
II-C-3 - Thread analyseur

Cela nous permettra de :
dtecter les verrous mortels (dead lock); dtecter les Conditions de course (Race conditions).
II-C-4 - Serveur d'application monitoring

Avec le serveur d'application, souvent il y a un module de monitoring. Cela nous permettra de : dtecter si la taille des pools est correcte.
II-C-5 - Base de donnes monitoring

La plupart des bases de donnes ont un outil de monitoring. Par exemple, Oracle dispose de DB Console. Cela nous permettra de : dtecter les requtes les plus lentes; dtecter les requtes les plus utilises; tuner les paramtres du serveur de base de donnes.
II-D - Corriger les problmes

Comme on le verra dans la suite, les corrections peuvent intervenir plusieurs endroits (configuration de la base de donnes, configuration de la JVM, au niveau source, ..) et pourront faire intervenir diffrentes personnes (DBA, dveloppeur, administrateur...). Une fois la correction faite, relancer les tests (on voit bien l'avantage d'avoir des tests automatiss dans ce cas) jusqu' atteindre les objectifs.
II-E - Superviser les serveurs de productions

Le test de performance/charge n'est qu'une simulation plus ou moins raliste et donc il est important de mettre sous surveillance les serveurs de productions.
III - Mesure des performances III-A - Test de charge

Pour le test de charge nous allons utiliser JMeter qui sera prsent de manire sommaire mais suffisante pour notre exemple. Vous trouverez plus d'informations sur http://blog.milamberspace.net/index.php/jmeter-pages
III-A-1 - Prsentation de JMeter

Plus d'informations ici
III-A-2 - Construction d'un plan de tests

Comme indiqu plus haut, cette tape il faut choisir avec les utilisateurs et/ou le chef de projet et/ou l'AMOA un certain nombre de scnarios et le nombre d'utilisateurs associs. Par exemple, supposons que l'application doive tenir la charge de 100 utilisateurs simultans et que :
90% des utilisateurs feront de la consultation ; 9% des utilisateurs feront de la modification ; 1% des utilisateurs feront de l'administration.
Dans ce cas un plan de test possible sera : Scnario Consultation descriptif Se connecter avec les droits Consultation Cliquer sur "Mes Elments" Se dconnecter Se connecter avec les droits Modification Cliquer sur "Mes Elments" Modifier le 1er lment Se dconnecter Se connecter avec les droits Administration Cliquer sur "Admin" Se dconnecter nombre d'utilisateurs
90
Modification
Administration
III-A-3 - Dvelopper un plan de test

III-A-3-a - Conception d'un scnario de test

Plus d'information ici.
III-A-4 - Excuter les tests

III-A-5 - Analyse des premiers rsultats

Pendant les tests de charge, afin de paramtrer l'application pour bien rpartir les traitements et avoir le maximum d'utilisateurs en simultane, il est souhaitable de bien configurer chaque pool (connexion, thread) de chaque serveur afin de diminuer les temps d'attente entre eux. Prenons une application n tiers classique Sur chaque partie il faut surveiller : Serveur web : taux d'occupation du pool de thread; nombre de thread en attente; taux d'occupation du processeur. Serveur d'application : taux d'occupation du pool de thread; nombre de thread en attente; taux d'occupation du processeur. Serveur de bases de donnes :
taux d'occupation du pool de connexion; nombre de connexions en attente; taux d'occupation du processeur.
Le principe est de paramtrer le nombre de connexion/thread sur chaque serveur afin : d'avoir un taux d'occupation processeur infrieur 80%; d'avoir un minimum de thread/connexion en attente; d'avoir un taux d'occupation des pools le plus haut possible.
Pour cela il faut bien avoir en tte que si un des tiers est surdimensionn par rapport au suivant, il va lui "donner trop de travail faire". Par exemple si le serveur d'application est capable de traiter beaucoup de demandes, il va demander au serveur de bases de donnes trop de requtes et donc devra attendre qu'il les traite. Or avec cette surcharge de travail, le serveur de bases de donnes va traiter de moins en moins rapidement les demandes.(Dans ce cas, c'est donc la base de donnes qui sera le goulot d'tranglement de l'architecture.) L'utilisation d'outils systme (vmstat, mpstat, iostat, DTrace, Gestionnaire des tches...) ou d'outils de monitoring pour surveiller un certain nombre de paramtres est une bonne ide. Pour avoir les temps de rponse des requtes/transactions changs entre l'application et JMeter, les items listeners de JMeter le font trs bien. Par exemple avec Summary Report, on a les mesures intressantes pour les temps de rponses : Average (ms) : moyenne des temps de rponse; Min (ms) : valeur du plus petit temps de rponse; Max (ms) : valeur du plus grand temps de rponse; Std. Dev. : l'cart-type.
Si les tests de charge sont concluants et que le taux d'occupation des serveurs est bon, le test peut s'arrter.
IV - Identifier et corriger les problmes

Si les tests de charge n'ont pas t concluants, il va falloir chercher d'o vient le problme. Pour cela il existe un certain nombre d'outils. Les problmes possibles sont ici regroups avec une solution possible et comment le dtecter.
IV-A - Consommation CPU

Avec le test de charge on a pu avoir des temps de rponse de manire globale, il est temps de regarder de manire plus prcise.
A l'aide du profiler, on va pouvoir calculer pour chaque package/class/mthode/... du programme : le temps d'excution; le nombre d'utilisations.
Il faudra chercher optimiser les parties : ayant le plus grand temps d'excution et utiliser un certain nombre de fois; utilises de nombreuses fois.
Il faut faire attention, un temps d'excution d'une mthode peut tre long car il est en attente de quelque chose (par exemple le rsultat d'une requte SQL) et dans ce cas l, la partie optimiser est la requte SQL et non la mthode en elle-mme. Avant de passer l'optimisation, vrifier que les algorithmes utiliss sont performants car il n'y aura pas de miracle s'il y a eu un mauvais choix de ce ct. De mme, si le taux d'occupation processeur est suprieur 80%, il faut adapter chaque partie de l'architecture afin de descendre en dessous de 80%. Si cela n'est pas possible, il faut envisager d'augmenter les capacits hardware des serveurs. Pour augmenter les capacits hardware, on peut : ajouter de la mmoire, mettre un disque dur plus rapide...; multiplier les serveurs et faire du Load balancing.
- 10 Copyright 2011 - Gomes Rodrigues Antonio. 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' 3 ans de prison et jusqu' 300 000 E de dommages et intrts. Droits de diffusion permanents accords developpez LLC.
IV-B - Consommation mmoire

Si lors des tests de charge on dtecte : consommation de mmoire trop importante; consommation de mmoire qui ne fait qu'augmenter; ou pire, un crash avec un OutOfMemory; un comportement trange du Garbage Collector (GC); une frquence d'excution du GC trop grande.
C'est qu'il faut regarder d'un peu plus prs la gestion de la mmoire.
IV-B-1 - Comment marche la mmoire

Avant de commencer il est important de savoir comment est gre la mmoire par la JVM. Attention, les JVM (en fonction de la version et de l'diteur (SUN, IBM...)) ne marchent pas toutes pareilles. Prenons par exemple la JVM 5 de SUN. La mmoire est compose de deux zones : la Heap : cette zone mmoire permet d'allouer les objets courants. Les options Xmx et Xms permettent de faire varier sa taille; la Permanent Generation (Permanent Space) : cette zone est rserve au chargement des classes. L'option XX:MaxPermSize permet de dfinir sa taille maximum.
La Heap est compose de deux zones : New Generation : c'est dans cette zone mmoire que sont allous les nouveaux objets. Les options XX:MaxNewSize et XX:NewSize permettent de faire varier sa taille; Old Generation : c'est ici que les objets avec une longue dure de vie se retrouvent un moment.
La New Generation est compose de deux zones : Eden Survivor. L'option XX:SurvivorRatio permet de dfinir sa taille. From To
En plus des zones mmoire, il y a le GC (garbage collector) qui supprime de la mmoire les objets non utiliss (objets qui ne sont plus rattachs la GC root). Il existe deux types de GC : Minor GC : qui s'excute rapidement et frquemment sur la zone New Generation; Major/full GC : qui s'excute plus lentement (tous les processus sont arrts...) et moins souvent et seulement sur la zone Old Generation.
Le principe de fonctionnement de la Heap est le suivant : lors de l'allocation d'un objet, il est plac dans la zone mmoire Eden; lorsque la zone Eden est pleine, un minor GC est excut et les objets vivants sont copis dans From; lorsque la zone From est pleine, un minor GC est excut et les objets vivants sont copis dans To; lorsque la zone To est pleine, les objets sont copis dans Old Generation; lorsque la zone Old Generation est pleine, un major/full GC est excut.
De ces explications, on peut en conclure qu'il faut minimiser les major GC. Pour cela il est important de : prfrer les objets avec une courte dure de vie afin d'viter de passer dans la zone Old Generation; ajuster la taille de la zone Young Generation. SUN prconise que la taille de la zone Young Generation soit infrieure 50% de la taille de la Heap; la taille minimum de la Heap (option -Xms) doit tre suffisante pour viter qu'elle ne croisse (car pour crotre il faut un major GC); la taille maximale de la Heap (option -Xmx) doit tre suprieure sa taille minimale pour viter les crashes ou gale pour plus de performance.
On peut aussi paramtrer le fonctionnement de la GC. Par exemple le paramtre -XX:+UseParallelGC pour les serveurs multi processeur (normalement c'est automatique pour ce type de machine) Il y a de nombreux outils qui nous permettent de surveiller l'activit du GC (VisualVM, VisualGC...). On pourra vrifier : l'utilisation de la Heap : taille utilise, taille maximale...; la frquence de l'activit du GC; le temps de l'excution de la GC; le type de GC excut.
Afin d'avoir des informations sur le GC, ajouter -verbose:gc, -XX:+PrintGCTimeStamps, -XX:+PrintGCDetails aux paramtres de la JVM Pour avoir plus d'information sur la gestion de la mmoire par la JVM http://gfx.developpez.com/tutoriel/java/gc/ Pour les options de la JVM http://blogs.sun.com/watt/resource/jvm-options-list.html Pour des conseils de tuning http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html
IV-B-2 - Fuite de mmoire

Comme on l'a vu sur la partie fonctionnement de la mmoire, les objets de la fuite de mmoire ont de fortes chances de se trouver dans la zone mmoire Old Generation et donc afin de gagner du temps, on peut se concentrer sur cette partie. Les 2 problmes majeurs viennent de la mauvaise utilisation : des objets en HTTP session; des collections.
Il existe de nombreuses mthodes permettant de trouver une fuite mmoire. Mais avant de commencer il est important de savoir qu'un OutOfMemoryError ne vient pas forcement d'une fuite de mmoire. Donc le premire chose faire est de bien paramtrer la configuration mmoire de la JVM.
IV-B-2-a - Analyse de fuite de mmoire partir de dump

Un dump est une copie de tout ce qu'il y a en mmoire de la JVM. De cette manire on peut savoir le nombre d'objets vivants, leurs consommations mmoire... On cre le dump.
Il existe plusieurs moyens En paramtrant la JVM avec les options : -XX:+HeapDumpOnOutOfMemoryError Un fichier dump est cr lors d'un OutOfMemoryError. -XX:+HeapDumpOnCtrlBreak Un fichier dump est cr lors d'un appui sur CTRL+BREAK sous Windows ou un kill -3 pid sous Unix.
Avec des outils : Sun JMap jmap.exe -dump:format=b,file=HeapDump.hprof pid (pid est obtenu avec jps). Sun JConsole Commande dumpHeap. Outils SAP JVMMon/MMC Dans le menu il y a "Dump Stack Trace". VisualVM; Netbeans; ...
On traite le dump.
En fonction de l'diteur de la JVM, on pourra ouvrir le dump avec un certain nombre d'outils comme : JHAT; NetBeans Profiler; VisualVM; SAP Memory Analyzer;
...
On analyse le dump.
L encore, de nombreuses mthodes peuvent tre utilises. Par exemple on peut comparer 2 dumps (avant lancement du traitement et aprs le traitement) afin de visualiser les objets qui restent en mmoire aprs traitement. Un autre point de dpart est de reprer les objets qui consomment normment de mmoire. Une fois les objets choisis (quel que soit le point de dpart), le principe est d'aller dans les dtails jusqu' trouver la fuite mmoire dans le code.
IV-B-3 - Utilisation des chanes de caractres

La mauvaise gestion des chanes de caractres en Java peut engendrer une surcration d'objets et une surconsommation de mmoire. Par exemple : pour concatner les chanes de caractres, utiliser la classe StringBuffer/StringBuilder; prfrer String s = "MaChaineDeCaracteres" String s = new String("MaChaineDeCaracteres"); crer les chanes de caractres avec la bonne taille (Findbugs peut vous y aider); ...
Attention car avec le compilateur JIT (Just In Time), cela n'est pas toujours ncessaire. On peut dtecter une mauvaise utilisation des chanes de caractres de la manire suivante. Pour cela on va partir de ce code Mauvaise utilisation des chanes de caractres
package teststring; public class Main { public static void main(String[] args) { String s = "MaChaineDeCaractere"; for (int i = 0; i < 100000; i++) { s = s + "Ajout"; } } }
Puis profilons ce code. Regardons d'un peu plus prs la mmoire
On remarque qu'il y a beaucoup d'allocations de char[] ou de String. Et donc que ce projet est un bon candidat pour l'utilisation de StringBuffer. Pour information, le temps d'excution est de 1.73 s
Maintenant changeons le String en StringBuffer Utilisation de StringBuffer

package teststring; public class Main { public static void main(String[] args) { StringBuffer s = new StringBuffer("MaChaineDeCaractere"); for (int i = 0; i < 100000; i++) { s.append("Ajout"); } } }
On remarque que maintenant il y beaucoup moins d'allocations de Char[] en mmoire
Le temps d'excution passe 0.0036 s
Puis changeons les StringBuffer en StringBuilder car on n'a pas besoin d'tre thread-safe Utilisation de StringBuilder
package teststring; public class Main { public static void main(String[] args) { StringBuilder s = new StringBuilder("MaChaineDeCaractere"); for (int i = 0; i < 100000; i++) { s.append("Ajout"); } } }
Le nombre d'allocations de Char[] en mmoire reste identique mais le temps d'excution descend 0.0034 s
Maintenant, initialisons le StringBuilder directement avec la bonne taille Utilisation de StringBuilder avec la bonne taille
package teststring; public class Main { public static void main(String[] args) { StringBuilder s = new StringBuilder(50019); s.append("MaChaineDeCaractere"); for (int i = 0; i < 100000; i++) { s.append("Ajout"); } } }
Le nombre d'allocation de Char[] diminue
Le temps d'excution passe 0.0034 s
Avec ces quelques conseils on a russi diminuer : le temps d'excution; le nombre d'allocation de Char[] et donc les frquences du fonctionnement du GC.
Et cela assez facilement en profilant la mmoire.
IV-B-4 - Trop d'objets

Comme vu prcdemment, la cration d'objets augmente la frquence de dclenchement du GC. Et donc il faut viter la cration d'objets inutiles. Par exemple : sortir si c'est possible la cration d'objets des boucles; utilisation de Integer.parseInt(s) la place de Integer.valueOf(s).intValue(); ...
Il y a un certain nombre de rgles dans FindBugs et PMD qui permettent de trouver ces points dans le code source de l'application. Sinon il faut regarder le graphe du GC.
IV-B-5 - Frameworks de persistance : Hibernate

Les frameworks de persistance sont pratiques mais il faut faire attention leur utilisation car il y a beaucoup de choses qui sont "caches". Nous allons nous focaliser sur Hibernate. La premire chose faire si on a des doutes sur Hibernate est d'activer les logs pour savoir exactement ce qu'il se passe. Pour cela il faut mettre true le paramtre hibernate.show_sql Il est aussi possible d'activer les statistiques pour encore plus d'informations avec le paramtre hibernate.generate_statistics Plus d'informations sur mon premier article sur Hibernate Une fois cela fait, on va travailler sur 2 parties, les cls primaires auto-incrmentes et les stratgies de chargement. Et enfin on verra une manire de faire des recherches multicritres avec Hibernate. Quelques conseils peuvent se trouver sur www.javalobby.org/articles/hibernate-query-101/ N'hsitez pas faire appel un DBA si c'est possible. http://blog.octo.com/anti-pattern-hibernate/et http://
IV-B-5-a - Cls primaires auto-incrmentes

Par dfaut, Hibernate ncessite 2 requtes SQL pour insrer un objet dans une table avec une cl primaire auto incrment. En effet, l'lment generator (qui est utilis pour dfinir la stratgie utilise pour gnrer les identifiants uniques) vaut identity ou sequence en fonction de la base de donnes. Or ce n'est pas la stratgie optimale et donc il peut tre utile d'utiliser les valeurs hilo ou seqhilo afin d'optimiser le temps d'insertion. Plus d'informations sur le site officiel.
IV-B-5-b - Les stratgies de chargement

Lors d'une requte SQL, Hibernate ne ragira pas de la mme faon pour charger les rsultats en fonction d'un certain nombre de paramtres. C'est pourquoi il est important de bien dfinir la stratgie de chargement afin d'viter le syndrome du N+1 selects (on excute une requte de plus que ncessaire). Les stratgies de chargement sont divises en 2 groupes qui sont le quand et le comment. Pour le quand, il y a : chargement immdiat : Hibernate charge toutes les donnes ncessaires immdiatement; chargement tardif : Hibernate charge les donnes seulement lorsque cela est ncessaire.
Il faut donc faire trs attention si on bascule (par dfaut on est en chargement tardif) sur le mode chargement immdiat afin de ne pas surcharger la mmoire.
Pour le comment, c'est la manire de grer les associations et on a le choix entre : chargement par select : c'est celui par dfaut et X Select seront excuts lorsqu'on accde l'association; chargement par sous-select : Le 1er Select rcupre tous les paramtres de la clause Where du 2e Select; chargement par jointure : Un seul Select avec jointure est utilis pour accder l'association; chargement par lot : Un seul Select est utilis.
Pour rsumer, il faut faire attention la combinaison du quand et du comment. Mais une fois matris c'est un bon moyen de diminuer le nombre de requtes SQL en particulier lorsque l'objet Pre contient une trs grande collection d'enfants. Plus d'informations sur le site officiel, sur http://bmarchesson.developpez.com/tutoriels/java/hibernate/ chargement/ et sur mon tutoriel.
IV-B-5-c - Recherche multicritre

Lorsqu'on a une recherche multicritre faire, il peut tre judicieux d'utiliser l'API Criteria de Hibernate afin d'viter la construction d'une requte HQL la vole. Plus d'informations sur http://java.developpez.com/faq/hibernate/?page=Criteria et http://www.javalobby.org/ articles/hibernatequery102/
IV-C - Optimisation de la partie base de donnes

Lors du dveloppement d'une application, souvent les dveloppeurs dveloppent et recettent sur une volumtrie bien plus faible que celle de la production relle. Les temps de rponse ainsi obtenus peuvent tre raisonnables malgr des requtes mal crites et ce n'est que lors des tests de charge ou en production que les problmes apparaissent. C'est pour cela qu'il est important d'avoir un environnement de test avec le mme jeu de donnes et l'aide d'un DBA si c'est possible. Si les performances de l'application sont critiques, on peut sacrifier l'interportabilit en utilisant au maximum toutes les spcificits du serveur de bases de donnes utilis. Plus d'informations sur http://wiki.postgresql.org/wiki/Performance_Optimization et http://sqlpro.developpez.com/cours/optimiser/ Voyons maintenant comment optimiser les performances.
IV-C-1 - Pool de connexion JDBC

Un pool de connexion permet de crer un certain nombre de connexions au dmarrage du serveur d'application. Cela permet de ne pas crer de connexion (process qui est trs gourmand) en cours de vie de l'application. Si on se retrouve avec trop de connexions en attente, il peut tre utile d'augmenter le pool de connexion JDBC du serveur d'application. Il faut faire attention au moins 2 choses afin de choisir le bon nombre : la charge processeur ne doit pas dpasser 80%; ce nombre dpend aussi du nombre de thread.
IV-C-2 - TableSpace
Un tablespace est l'espace de stockage o sont stocks les objets de la base de donnes. Il faut bien dfinir les tablespace en les rpartissant sur plusieurs disques durs si ncessaire. Par exemple il peut tre judicieux de placer les objets (indexes, tables...) souvent utiliss dans un ou plusieurs tablespaces sur les disques durs les plus rapides. Plus d'informations sur http://oracle.developpez.com/guide/architecture/tablespaces/
IV-C-3 - Gnration des statistiques

Afin de dterminer le meilleur plan d'excution d'une requte, les serveurs de base de donnes utilisent une srie de statistiques. Cela signifie qu'en fonction de divers paramtres (volumtrie, rpartition des donnes...) on aura un plan d'excution diffrent et que ce plan d'excution pourra voluer avec le temps. Donc il est important que ces statistiques soient jour. Pour cela il existe des outils spcifiques chaque base de donnes comme Runstats sous DB2, DBMS_STATS sous Oracle et VACUUM sous PostgreSQL. Il peut tre utile de rcuprer les statistiques de la base de donnes en production et de les mettre sur la machine de test afin de pouvoir reproduire les problmes.
IV-C-4 - Dtecter les requtes coteuses

De nombreux outils permettent d'avoir un historique des requtes excutes par l'application. Sous Oracle 10g il y a AWR (Automatic Workload Repository) et STATPACK. Plus d'information sur STATPACK : http://oracle.developpez.com/guide/tuning/statpack/ Sous Oracle, on a aussi la vue systme nomme v$sqlarea qui le permet. Par exemple avec cette vue on pourra avoir les informations suivantes : Sql_FullText : l'ordre sql; cpu_time : temps CPU; elapsed_time : temps d'excution; fetches : nombre de lignes retournes; buffer_gets : le nombre de block mmoire lus; disk_reads : le nombre de block disque lus; executions : le nombre d'excutions; rows_processed : le nombre de lignes traites;
Avec ces informations, on peut diagnostiquer un certain nombre de problmes. Pour MySQL, on peut lancer le serveur avec les options --log-slow-queries et --log-queries-not-using-indexes afin d'avoir les requtes qui posent problmes dans un fichier log.
IV-C-4-a - Plan d'excution d'une requte

Une fois les requtes coteuses dtectes, on va essayer de savoir pourquoi elles le sont. Pour cela on peut activer les traces (sous Oracle avec la commande SET AUTOTRACE ON) ou de faire un explain sur une requte. Cela nous permettra d'avoir le plan d'excution de la requte afin de savoir comment elle se comporte exactement. Par exemple, on pourra savoir si elle utilise un index et son cot. Voil un exemple de l'utilisation d'un EXPLAIN sous PostgreSQL. Utilisation de Explain sous PostgreSQL
select * from db_order join db_order_item on db_order.id=db_order_item.order_id where customer_id= 4
donne
Rsultat de Explain
"Hash Join (cost=6.81..39.65 rows=20 width=56) (actual time=0.231..5.050 rows=16 loops=1)" " Hash Cond: (db_order_item.order_id = db_order.id)" " -> Seq Scan on db_order_item (cost=0.00..27.01 rows=1501 width=32) (actual time=0.023..2.291 rows=1501 loops=1)" " -> Hash (cost=6.76..6.76 rows=4 width=24) (actual time=0.177..0.177 rows=4 loops=1)" " -> Seq Scan on db_order (cost=0.00..6.76 rows=4 width=24) (actual time=0.081..0.161 rows=4 loops=1)" " Filter: (customer_id = 4)" "Total runtime: 5.255 ms"
Et de mannire visuelle
Afin de pouvoir tudier le rsultat il faut savoir que : Accs aux donnes des tables Parcours squentiel : Full Table Scans La table est directement lue partir du disque dur et n'utilise ni le cache, ni aucun index. ... Parcours d'index : Index Full Scan L'index est directement lu partir du disque dur et n'utilise pas le cache. Fast Full Index Scan La mme chose que Index Full Scan mais en plus rapide (la stratgie de lecture sur disque dur n'est pas la mme). ... ROWID Scan Accs direct un ensemble de tuples Jointure Nested Loops Lorsque 2 tables sont jointes par Nested Loops, il y en a donc une qui boucle sur une autre. Hash Join Une table de hachage est cre pour la jointure. ... Pour le SET AUTOTRACE ON
Recursives calls : Une instruction SQL appelle d'autres requtes SQL.

Consistents gets : Lecture dans le cache de Oracle.
IV-C-4-b - Index
Avec le plan d'excution d'une requte on peut se rendre compte de 2 choses. La 1re chose est qu'il faut ajouter un index afin d'acclrer la requte Avant d'ajouter un index, il est important de savoir qu'un index acclre les lectures mais ralentit les critures. Les index seront crs en priorit lorsque : une ou plusieurs colonnes sont frquemment utilises dans une clause where ou dans une condition de jointure; la table est de grande taille et que la plupart des requtes ne ramnent qu'un nombre restreint de lignes.
Faire attention ce que : l'index soit suffisamment discriminant; l'ordre des colonnes composant un index composite soit le plus pertinent.
Une fois qu'on a choisi les colonnes composant l'index, il ne reste plus que choisir le type d'index. Par exemple un index de type B-tree par dfaut et un index bitmap lorsqu'il porte sur une colonne avec trs peu de valeurs distinctes. et avec peu d'insertions. La 2e chose est que malgr la prsence d'un index celui-ci n'est pas utilis. Cela est d au fait que pour que l'index soit utilis, il faut respecter un certain nombre de rgles comme : ne pas utiliser l'oprateur IS NULL ou IS NOT NULL dans une colonne indexe (du moins pour un index de type B-tree); lorsque l'oprateur LIKE est utilis sur une colonne indexe, ne pas dbuter par %; ne pas utiliser de fonction comme upper...
IV-C-4-c - Dlais d'attente

S'il y a un gros cart entre le cpu_time et le elapsed_time, c'est qu'il y a des dlais d'attentes qui peuvent tre divers (accs disques, verrous,...). Pour les verrous, vrifier si le niveau d'isolation est correct afin d'en viter le maximum. Par exemple avec un mauvais niveau d'isolation, une table entire peut avoir un verrou alors qu'il pourrait tre sur seulement une ligne.
Par exemple sous PostgreSQL :

Pour savoir s'il y a des locks SELECT * FROM pg_locks; le changement de niveau d'isolation peut se faire avec SET TRANSACTION ISOLATION LEVEL; ajouter FOR UPDATE la fin d'une requte SQL pour bloquer une ligne SELECT 1 FROM table1 WHERE id_table1 > 5 FOR UPDATE;
Une solution plus gnrique est d'utiliser les fonctions setTransactionIsolation() de l'interface Connection. Utilisation de setTransactionIsolation()
Connection conn = JdbcManager.getConnection(); conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
Pour viter les dlais dus au rseau, il peut tre utile : d'utiliser des procdures stockes; minimiser les datas retourns par les requtes (viter les Select * from ...); utiliser des caches; ...
Pour diminuer les accs disque, il peut tre utile de : ajouter des index; augmenter le paramtre mmoire du SGBD (SGA/PGA pour Oracle...); prendre une machine plus puissante; ...
IV-C-4-d - Optimisation des requtes SQL

Il est temps d'optimiser les requtes SQL, pour cela allez sur http://sqlpro.developpez.com/cours/optimiser/ De mme il faut passer un peu de temps comprendre comment marche l'optimiseur de requte de la base de donnes utilis afin d'avoir les meilleures performances possibles. Par exemple sous Oracle 9i, les requtes sont excutes plus rapidement si les tables sont classes par ordre dcroissant (par rapport la taille) dans les clauses FROM et WHERE. Une autre solution est d'utiliser la fonctionnalit SQL Optimizer de Quest Toad.
IV-C-5 - Utilisation de JDBC

Maintenant que les requtes, le schma et le serveur ont t optimiss, il est temps de passer au niveau JDBC. La premire chose faire si cela est possible est de choisir le bon driver JDBC. En fonction des exigences on pourra prendre le plus rapide ou le plus complet ou ... Aprs il faut vrifier que toutes les ressources (Connexions, Statements, ResultSets) sont bien fermes lorsqu'elles ne sont plus utilises. Pour cela on peut utiliser PMD/Findbugs en complment d'une revue de code. Une fois cela fait il faut choisir le bon nombre de connexions possibles qu'il faudra paramtrer dans le pool de connexion du serveur d'application. Ne pas oublier de changer la valeur du nombre de thread pour qu'elle soit suffisante pour ouvrir assez de connexions.
Regardons un peu plus dans le code source de l'application. Reprons les Statements qui vont tre appels de nombreuses fois et changeons-les par des PreparedStatement. L'avantage des instances PreparedStatement est qu'elles contiennent une instruction SQL dj compile. Utilisation de PreparedStatement
PreparedStatement pstmt = con.prepareStatement("UPDATE table SET i = ? WHERE j = ?"); pstmt.setLong(1, 123); pstmt.setLong(2, 100);
Si le driver JDBC le permet, on peut activer le cache pour les PreparedStatement. Plus d'informations sur http://java.developpez.com/faq/jdbc/?page=preparedstatement Une autre astuce peut tre de regrouper les requtes dans un batch Utilisation de batch
Connection con = DriverManager.getConnection(.......);
Utilisation de batch
Statement stmt = con.createStatement(); stmt.addBatch("INSERT INTO Adresse ......."); stmt.addBatch("INSERT INTO Contacte ......."); int[] countUpdates = stmt.executeBatch();
ou de regrouper les requtes dans une transaction de la manire suivante : Transaction manuelle
setAutoCommit(false); // Executer toute les requtes ExecuteUpdate();
On retrouvera ces conseils et d'autres sur http://www.precisejava.com/javaperf/j2ee/JDBC.htm
IV-C-6 - Frameworks de persistance : Hibernate

Il est important de configurer Hibernate finement et d'utiliser des jointures afin d'viter trop de requtes. Pour plus d'informations, reportez-vous la partie consommation mmoire et sur mon article sur Hibernate
IV-D - Performance d'affichage d'une page Web

Il est important que la partie interface graphique soit fluide et rapide car cela sera le point d'entre pour l'utilisateur. Une des premires choses faire est de vrifier que les JSP sont pr-compils.
Sinon voila quelques astuces : Compression des ressources statiques (images, fichiers flashs, scripts...) afin de rduire le poids gnral en octets d'un cran, comparer la taille entre un fichier PNG8 et un fichier GIF et prendre le plus petit; supprimer les meta data des fichiers images (EXIFpour les JPEG, chunks pour les PNG...). mettre en place une politique d'expiration des ressources statiques; activer la compression HTTP afin de rduire les donnes transitant entre le serveur Web et l'utilisateur final; utiliser des CSS sprite (une seule image dcoupe par une CSS).
Vous trouverez toutes ces rgles et bien plus sur http://developer.yahoo.com/performance/rules.html On peut utiliser le plugin YSlow afin de nous aider appliquer ces rgles. Il faut faire attention aux crans de recherche. Lors d'une excution d'une recherche, cela ne sert rien de rcuprer tous les rsultats si on n'affiche que 10 la fois. Il existe des frameworks pour cela comme HDPagination.
Pour les applications en JSP avec beaucoup d'crans, il peut tre utile d'augmenter la taille mmoire de la zone Permanent Generation de la JVM (option XX:MaxPermSize). Continuons un peu avec les JSP.
IV-D-1 - Tuning du serveur d'application pour les JSP

JSP Reload et JSP Development Mode.
Si l'application est en production, on peut dsactiver un certain nombres d'tapes du cycle de vie d'une JSP Par exemple chaque requte pour une JSP, Tomcat vrifie si cette JSP a t modifie. Cela est trs utile en dveloppement pour ne pas avoir redployer l'application chaque modification de la JSP mais inutile en production. Pour gagner du temps, il suffit de modifier les valeurs false des paramtres development et reloading de la servlet Jasper dans le fichier Tomcat Home/conf/web.xml web.xml
<servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> ... <init-param> <param-name>development</param-name> <param-value>false</param-value> </init-param> <init-param> <param-name>reloading</param-name> <param-value>false</param-value> </init-param> ... </servlet>
genStrAsCharArray.
De mme on peut forcer la gnration en char arrays de tous les static strings de la JSP. Cela vite l'utilisation de toCharArray() chaque fois. web.xml
<servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> ... <init-param> <param-name>genStrAsCharArray</param-name> <param-value>true</param-value> </init-param> ... </servlet>
Pool de Custom Tags.
Il est possible d'activer un pool pour l'utilisation des Custom Tags.
Pour l'activer, modifions la valeur true du paramtre enablePooling de la servlet Jasper dans le fichier Tomcat Home/conf/web.xml web.xml
<servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> ... <init-param> <param-name>enablePooling</param-name> <param-value>true</param-value> </init-param> ... </servlet>
Il faut faire attention si on a de "grosses" JSP car on peut avoir une exception OutOfMemory. Si cela arrive (ou que lorsqu'on profile l'application, on se retrouve avec BodyContentImpl qui consomme beaucoup de mmoire), on peut paramtrer dans le fichier de dmarrage de Tomcat : org.apache.jasper.runtime.JspFactoryImpl.USE_POOL = false org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER = false Dsactiver l'Auto-Deploy.
Lorsque Tomcat trouve un nouveau WAR dans son rpertoire webapps, il le dploie automatiquement. Pour dsactiver cette fonction, il faut modifier le fichier Tomcat Home/conf/server.xml server.xml
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="false" xmlValidation="false" xmlNamespaceAware="false">
ou dans l'interface d'administration du serveur d'application
IV-E - Problmes de thread

Les principaux problmes lis aux threads sont :
Dead lock : au moins 2 threads se bloquent pour accder une ressource; Race conditions : au moins 2 threads entrent en comptition pour obtenir une ressource et donc le nombre de threads augmente et il faut de plus en plus de temps pour accder la ressource; Thread Leak : on cre des thread sans fin jusqu' avoir un OutOfMemory: unable to create new native thread; Problme de configuration du pool de thread : le nombre de thread configur dans le pool est suprieur au nombre maximum de thread de la JVM.
La correction de ces problmes peut aller de simplement changer le nombre de threads disponibles dans le pool de connexion la modification du code source. On peut dtecter ces problmes avec : VisualVM, Netbeans : Etat des threads; JConsole : Statistiques des contentions des threads.
IV-E-1 - Pool de Thread

La 1re chose faire si cela n'a pas dj t fait est de vrifier le taux d'occupation du pool de thread et le nombre de thread en attente. En fonction de ces 2 valeurs, il faudra augmenter ou diminuer dans le serveur d'application le nombre de threads. Mark Thomas (Consultant chez SpringSource) conseille dans "Tomcat Optimisation et Performance Tuning" d'avoir en production entre 200 et 800 threads (400 comme valeur de dpart). Il faut bien faire attention ne pas mettre un nombre trop grand sous peine de surcharger la machine (taux d'occupation processeur infrieur 80%) et de surcharger le serveur de bases de donnes.
IV-E-2 - Serveur web

Comme on l'a dj vu, il faut paramtrer au mieux tous les pools (serveur web, JDBC, serveur d'application) afin de limiter les temps d'attente. Prenons comme exemple, Glassfish HTTP Acceptor Threads.
HTTP Acceptor Threads permet de : accepter de nouvelles connexions; grer les nouvelles requtes associes aux connexions existantes.
Dans la console d'administration de Glassfish Configuration -> HTTP Service -> HTTP Listeners -> http-listener-1 Puis mettre le bonne valeur dans "Acceptor Threads" Il est recommand de mettre 1 Thread pour 1 4 coeurs (donc sur un dual core, pas besoin de changer la valeur par dfaut qui est de 1).
HTTP Request Processing Threads.
HTTP Request Processing Threads permet de grer les requtes HTTP entrantes. Dans la console d'administration de Glassfish Configuration -> HTTP Service -> RequestProcessing Puis mettre le bonne valeur dans "Thread Count"
IV-E-3 - JVM
Certaines options de la JVM permettent d'amliorer les performances. Par exemple l'option -XX:+UseBiasedLocking de la JVM de Sun ( partir de JDK 5.0_06 et activer par dfaut dans JDK 6).
IV-E-4 - Niveau programme

D'un point de vue code source, s'il n'y a pas de problme d'algorithme, les 2 principaux moyens de rduire les problmes de threads sont : minimiser le primtre des blocs synchroniss; utiliser des objets non synchroniss (ArrayList, StringBuilder...).
IV-E-4-a - Blocs synchroniss

Les blocs synchroniss permettent de rendre une partie du code accessible seulement un thread la fois. L'inconvnient est que si la dure de traitement de ce bloc de code est grande, les autres threads vont devoir attendre. Pour viter au maximum cette attente, il faut synchroniser la plus petite partie possible. Par exemple ne pas synchroniser une fonction complte si seulement une seule partie de cette fonction doit tre synchronise. On peut aussi utiliser ReentrantReadWriteLock afin d'avoir plusieurs locks en lecture en mme temps mais qu'un seul lock en criture. De plus penser utiliser java.util.concurrent ou backport-util-concurrent si votre version de la JVM ne le permet pas.
IV-E-4-b - Objets non synchroniss

Il ne faut utiliser des objets ThreadSafe que si cela est ncessaire afin d'viter des locks inutiles. Pour dtecter une surconsommation de ces objets, on peut faire un profilage de mmoire. Par exemple pour la HashTable et le Vector. Si on observe trop de Hashtable en mmoire, vrifier que l'accs synchronis est ncessaire. Si cela n'est pas le cas, utiliser plutt un ArrayList Sinon prfrer ConcurrentHashMap Si on observe trop de Vector en mmoire, vrifier que l'accs synchronis est ncessaire. Si cela n'est pas le cas, utiliser plutt un HashMap Sinon prfrer LinkedBlockingDeque, ArrayBlockingQueue, ConcurrentLinkedQueue, LinkedBlockingQueue ou PriorityBlockingQueue.
IV-F - Exception
Comme indiqu sur http://blog.developpez.com/adiguba/p1075/java/perfs/exception-et-performances/les exceptions sont coteuses mais indispensables. Par contre n'utiliser les exceptions que pour ce qu'elles ont t cres par les ingnieurs SUN. Par exemple ne pas utiliser d'exception pour le contrle de flux comme ci dessous : Mauvaise utilisation des exceptions
try { int i = 0; while (true) Tableau[i++].lireValeur(); } catch (ArrayIndexOutOfBoundsException e) { }
ou Mauvaise utilisation des exceptions

int i = 0;
Mauvaise utilisation des exceptions
while (true) { i = i + 1; throw new FinAdditionException(); }
Pour reprer ce genre de mauvaise utilisation des exceptions, lors du profilage de la mmoire, vrifier le nombre d'allocations d'objets Exception ou utiliser la fonction de Yourkit Java Profiler. Penser aussi bien configurer le niveau de log.
IV-G - Utilisation de cache

S'il n'y a pas de problme de consommation de mmoire, il peut tre utile d'ajouter des caches entre certaines couches de son application. Pour que les performances du cache soient optimales, il faut faire attention la taille des caches.
IV-H - flux d'entres/sorties

Pour tout ce qui est flux d'entres/sorties, les buffers sont utiles. Par exemple prfrez utiliser l'API java.nio la place de l'API java.io. Attention ce n'est pas toujours le cas http://www.theserverside.com/news/thread.tss?thread_id=48449 Bien rgler le niveau de log peut tre utile. On peut surveiller les entres/sorties avec : Linux : iostat...; Solaris : DTrace...; Windows : Filemon...
V - Quelques astuces V-A - Copie de tableau

Pour la copie de tableau, prfrer l'utilisation de System.arrayCopy
V-B - Utiliser la dernire JVM si possible

Si cela est possible, pensez utiliser la dernire version de la JVM car Sun amliore rgulirement les performances de sa JVM, active un certain nombre d'options au fur et mesure et ajoute des outils. Par exemple : a partir de Java 1.5, plus besoin de jvm -server car la JVM dtecte automatiquement le contexte; l'option -XX:+UseBiasedLocking est activ seulement partir de la version 6; ...
VI - Conclusion
On a vu qu'atteindre l'objectif de performance que l'on s'est fix fait intervenir de nombreuses connaissances diverses phases du projet (dveloppement, paramtrage...). Sur les applications exigeantes en terme de performance, l'aide d'experts (DBA...) est un gros plus pour le succs du projet. Comme pour les autres types de recette (fonctionnelle...), la mthodologie est trs importante. Et surtout mesurer les performances avant d'optimiser. Aprs il faut se mfier des "trucs et astuces" que l'on trouve sur le net (y compris cet article) car elles dpendent du contexte qui n'est pas forcement le mme que sur vos projets. N'hsitez pas complter vos connaissances (cache EJB, JVM d'IBM, cration de jeux de test...).
VII - Remerciements
Remerciements DD77 pour sa relecture et son aide. Remerciements Milamber pour sa relecture et son aide. Remerciements Dut pour sa relecture orthographique. Remerciements ClaudeLELOUP pour sa relecture orthographique.
VIII - Rfrences
Documentations SUN : http://java.sun.com/performance/reference/whitepapers/6_performance.html http://java.sun.com/docs/hotspot/HotSpotFAQ.html Forum de JBoss sur la performance Forum de JBoss Blog de Ippon Technilogies o il y a un certain nombre d'articles sur les fuites mmoires http://blog.ippon.fr/ Blog de Xebia http://blog.xebia.fr/ Profiler de Netbeans http://profiler.netbeans.org/index.html Profiler commerciaux YourKit JProfiler Jprobe Apache JMeter http://groups.google.com/group/jmeter-fr/topics?hl=fr http://blog.milamberspace.net/ HP LoadRunner Site officiel

Audit J2EE

Transféré par

Droits d'auteur :

Formats disponibles

Audit J2EE

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Audit J2EE

Transféré par

Droits d'auteur :

Formats disponibles

Audit des performances d'une application en Java EE

par Antonio Gomes Rodrigues (arodrigues.developpez.com)

II-A - Prparation des tests

II-A-1 - Dfinition du type de test

II-A-2 - Dfinition des objectifs de performance

II-A-3 - Prparation de la machine cible

II-A-4 - Choix des scnarios

II-A-5 - Choix des outils

II-B - Mesure des performances

II-C - Identifier les problmes

II-C-1 - Memory debugger

Par exemple avec Yourkit Java Profiler.

Par exemple avec Yourkit Java Profiler.

II-C-3 - Thread analyseur

Par exemple avec Yourkit Java Profiler.

II-C-4 - Serveur d'application monitoring

II-C-5 - Base de donnes monitoring

II-D - Corriger les problmes

II-E - Superviser les serveurs de productions

III - Mesure des performances III-A - Test de charge

III-A-1 - Prsentation de JMeter

III-A-2 - Construction d'un plan de tests

III-A-3 - Dvelopper un plan de test

III-A-3-a - Conception d'un scnario de test

III-A-4 - Excuter les tests

III-A-5 - Analyse des premiers rsultats

IV - Identifier et corriger les problmes

IV-A - Consommation CPU

IV-B - Consommation mmoire

IV-B-1 - Comment marche la mmoire

IV-B-2 - Fuite de mmoire

IV-B-2-a - Analyse de fuite de mmoire partir de dump

IV-B-3 - Utilisation des chanes de caractres

Puis profilons ce code. Regardons d'un peu plus prs la mmoire

Maintenant changeons le String en StringBuffer Utilisation de StringBuffer

On remarque que maintenant il y beaucoup moins d'allocations de Char[] en mmoire

Le temps d'excution passe 0.0036 s

Le nombre d'allocation de Char[] diminue

Le temps d'excution passe 0.0034 s

Et cela assez facilement en profilant la mmoire.

IV-B-4 - Trop d'objets

IV-B-5 - Frameworks de persistance : Hibernate

IV-B-5-a - Cls primaires auto-incrmentes

IV-B-5-b - Les stratgies de chargement

IV-B-5-c - Recherche multicritre

IV-C - Optimisation de la partie base de donnes

IV-C-1 - Pool de connexion JDBC

IV-C-3 - Gnration des statistiques

IV-C-4 - Dtecter les requtes coteuses

IV-C-4-a - Plan d'excution d'une requte

Recursives calls : Une instruction SQL appelle d'autres requtes SQL.

Consistents gets : Lecture dans le cache de Oracle.

IV-C-4-c - Dlais d'attente

Par exemple sous PostgreSQL :

Connection conn = JdbcManager.getConnection(); conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);

IV-C-4-d - Optimisation des requtes SQL

IV-C-5 - Utilisation de JDBC

Connection con = DriverManager.getConnection(.......);

setAutoCommit(false); // Executer toute les requtes ExecuteUpdate();

On retrouvera ces conseils et d'autres sur http://www.precisejava.com/javaperf/j2ee/JDBC.htm