audit j2ee

7/31/2019 Audit J2EE

1/35

Audit des performances

d'une application en Java EE

parAntonio 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.
http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


2/35

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

- 2 -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 000E de dommages et intrts. Droits de diffusion permanents accords developpez LLC.

http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/

I - Introduction..............................................................................................................................................................4II - Procdure de test.................................................................................................................................................. 4

II-A - Prparation des tests....................................................................................................................................5II-A-1 - Dfinition du type de test..................................................................................................................... 5II-A-2 - Dfinition des objectifs de performance...............................................................................................5II-A-3 - Prparation de la machine cible.......................................................................................................... 6

II-A-4 - Choix des scnarios.............................................................................................................................6II-A-5 - Choix des outils....................................................................................................................................6II-B - Mesure des performances.......................................................................................................................6II-C - Identifier les problmes........................................................................................................................... 6

II-C-1 - Memory debugger...........................................................................................................................6II-C-2 - Profiler.............................................................................................................................................6II-C-3 - Thread analyseur............................................................................................................................ 6II-C-4 - Serveur d'application monitoring.....................................................................................................7II-C-5 - Base de donnes monitoring..........................................................................................................7

II-D - Corriger les problmes............................................................................................................................7II-E - Superviser les serveurs de productions.................................................................................................. 7

III - Mesure des performances...............................................................................................................................7

III-A - Test de charge........................................................................................................................................7III-A-1 - Prsentation de JMeter..................................................................................................................7III-A-2 - Construction d'un plan de tests..................................................................................................... 7III-A-3 - Dvelopper un plan de test........................................................................................................... 8

III-A-3-a - Conception d'un scnario de test..........................................................................................8III-A-4 - Excuter les tests...........................................................................................................................8III-A-5 - Analyse des premiers rsultats......................................................................................................8

IV - Identifier et corriger les problmes............................................................................................................... 10IV-A - Consommation CPU.............................................................................................................................10IV-B - Consommation mmoire...................................................................................................................... 11

IV-B-1 - Comment marche la mmoire.....................................................................................................11IV-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......................................................................................... 15IV-B-4 - Trop d'objets................................................................................................................................ 18IV-B-5 - Frameworks de persistance : Hibernate......................................................................................19

IV-B-5-a - Cls primaires auto-incrmentes...................................................................................... 19IV-B-5-b - Les stratgies de chargement............................................................................................ 19IV-B-5-c - Recherche multicritre.........................................................................................................20

IV-C - Optimisation de la partie base de donnes.........................................................................................20IV-C-1 - Pool de connexion JDBC............................................................................................................ 20IV-C-2 - TableSpace.................................................................................................................................. 21IV-C-3 - Gnration des statistiques.........................................................................................................22IV-C-4 - Dtecter les requtes coteuses.................................................................................................22

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

IV-C-4-b - Index....................................................................................................................................24IV-C-4-c - Dlais d'attente....................................................................................................................24IV-C-4-d - Optimisation des requtes SQL..........................................................................................25

IV-C-5 - Utilisation de JDBC..................................................................................................................... 25IV-C-6 - Frameworks de persistance : Hibernate......................................................................................27

IV-D - Performance d'affichage d'une page Web...........................................................................................27IV-D-1 - Tuning du serveur d'application pour les JSP.............................................................................28

IV-E - Problmes de thread............................................................................................................................29IV-E-1 - Pool de Thread............................................................................................................................30IV-E-2 - Serveur web.................................................................................................................................31IV-E-3 - JVM..............................................................................................................................................32IV-E-4 - Niveau programme...................................................................................................................... 33

IV-E-4-a - Blocs synchroniss..............................................................................................................33IV-E-4-b - Objets non synchroniss.....................................................................................................33

IV-F - Exception.............................................................................................................................................. 33
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


3/35




IV-G - Utilisation de cache..............................................................................................................................34IV-H - flux d'entres/sorties............................................................................................................................ 34

V - Quelques astuces...........................................................................................................................................34V-A - Copie de tableau...................................................................................................................................34V-B - Utiliser la dernire JVM si possible...................................................................................................... 34

VI - Conclusion.....................................................................................................................................................35

VII - Remerciements.............................................................................................................................................35VIII - Rfrences.................................................................................................................................................. 35


4/35




I - Introduction

Malgr l'augmentation de la puissance des machines, il arrive que les objectifs de performance d'une applicationJ2EE 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 quel'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 bonnedevise 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'utilisateurssimultans, 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 doncil est utile de collaborer avec des spcialistes, en particulier les administrateurs de serveurs d'applications et lesadministrateurs de bases de donnes (DBA).

Dernire chose importante, il faut se mfier des "Performance Tips" qui dpendent du contexte d'utilisation, parexemple 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 :
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/maven2/qualite/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


5/35




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.
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LIII-Fhttp://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LIII-Dhttp://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


6/35




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.


II-B - Mesure des performances

Dans cette partie, on utilisera des outils de test de charge (HP LoadRunner, Apache Jmeter...) pour simulerl'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 avecYourkit Java Profiler.

II-C-2 - Profiler


dcouvrir les goulots d'tranglement; avoir des mesures par ligne d'instruction.


II-C-3 - Thread analyseur

http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performance-avec-yourkit-java-profiler/#LIV-Ahttp://arodrigues.developpez.com/tutoriels/java/performance/audit-performance-avec-yourkit-java-profiler/#LVhttp://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LIII-Ehttp://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LIII-Bhttp://arodrigues.developpez.com/tutoriels/java/performance/plan-test-realiste/#LIII-Ihttp://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


7/35




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 basede 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 testsautomatiss 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 soussurveillance 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 notreexemple.Vous trouverez plus d'informations surhttp://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 :
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/developper-plan-test-avec-jmeter/#L2http://arodrigues.developpez.com/tutoriels/java/performance/developper-plan-test-avec-jmeter/#L2http://blog.milamberspace.net/index.php/jmeter-pageshttp://arodrigues.developpez.com/tutoriels/java/performance/audit-performance-avec-yourkit-java-profiler/#LIV-Bhttp://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


8/35




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 descriptif nombre d'utilisateurs

Consultation Se connecter avec les droitsConsultationCliquer sur "Mes Elments"Se dconnecter

90

Modification Se connecter avec les droitsModificationCliquer sur "Mes Elments"Modifier le 1er lmentSe dconnecter

9

Administration Se connecter avec les droitsAdministration

Cliquer sur "Admin"Se dconnecter

1

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 maximumd'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 :
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/developper-plan-test-avec-jmeter/#L7http://arodrigues.developpez.com/tutoriels/java/performance/developper-plan-test-avec-jmeter/#L5http://arodrigues.developpez.com/tutoriels/java/performance/developper-plan-test-avec-jmeter/#L4http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


9/35




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 "donnertrop de travail faire".Par exemple si le serveur d'application est capable de traiter beaucoup de demandes, il va demander au serveurde bases de donnes trop de requtes et donc devra attendre qu'il les traite. Or avec cette surcharge de travail, leserveur de bases de donnes va traiter de moins en moins rapidement les demandes.(Dans ce cas, c'est donc labase 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 listenersde 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.


10/35


11/35




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 defaire 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 (objetsqui 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.
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


12/35




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 lesserveurs 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.


13/35




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 JVMhttp://gfx.developpez.com/tutoriel/java/gc/

Pour les options de la JVMhttp://blogs.sun.com/watt/resource/jvm-options-list.html

Pour des conseils de tuninghttp://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 chancesde se trouver dans la zone mmoire Old Generation et donc afin de gagner du temps, on peut se concentrer surcette 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 importantde savoir qu'un OutOfMemoryError ne vient pas forcement d'une fuite de mmoire. Donc le premire chose faireest de bien paramtrer la configuration mmoire de la JVM.
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.htmlhttp://blogs.sun.com/watt/resource/jvm-options-list.htmlhttp://gfx.developpez.com/tutoriel/java/gc/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


14/35




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'objetsvivants, 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;


15/35




...

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 lesobjets 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' trouverla 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 unesurconsommation 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 caractrespackage teststring;

publicclass Main {

publicstaticvoid main(String[] args) {

String s ="MaChaineDeCaractere";

for (int i =0; i


16/35




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 StringBufferpackage teststring;

publicclass Main {


StringBuffer s =new StringBuffer("MaChaineDeCaractere");

for (int i =0; i


17/35




Puis changeons les StringBuffer en StringBuilder car on n'a pas besoin d'tre thread-safe

Utilisation de StringBuilderpackage teststring;

publicclass Main {


StringBuilder s =new StringBuilder("MaChaineDeCaractere");

for (int i =0; i


18/35




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 viterla 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 sourcede l'application.

Sinon il faut regarder le graphe du GC.


19/35




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'ilse passe.Pour cela il faut mettre true le paramtre hibernate.show_sqlIl est aussi possible d'activer les statistiques pour encore plus d'informations avec le paramtrehibernate.generate_statistics

Plus d'informations surmon 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 http://blog.octo.com/anti-pattern-hibernate/ et http://www.javalobby.org/articles/hibernate-query-101/

N'hsitez pas faire appel un DBA si c'est possible.

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) vautidentity ou sequence en fonction de la base de donnes. Or ce n'est pas la stratgie optimale et donc il peut tre utiled'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.
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://docs.jboss.org/hibernate/stable/core/reference/fr/html/mapping.html#mapping-declaration-id-enhanced-optimizershttp://www.javalobby.org/articles/hibernate-query-101/http://www.javalobby.org/articles/hibernate-query-101/http://blog.octo.com/anti-pattern-hibernate/http://arodrigues.developpez.com/tutoriels/java/performance/hibernate-performance-part1-strategies-chargement/#LVIhttp://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


20/35




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 bonmoyen de diminuer le nombre de requtes SQL en particulier lorsque l'objet Pre contient une trs grande collectiond'enfants.

Plus d'informations sur le site officiel, sur http://bmarchesson.developpez.com/tutoriels/java/hibernate/chargement/ et surmon 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 bienplus faible que celle de la production relle. Les temps de rponse ainsi obtenus peuvent tre raisonnables malgrdes 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 toutesles spcificits du serveur de bases de donnes utilis.

Plus d'informations surhttp://wiki.postgresql.org/wiki/Performance_Optimization

ethttp://sqlpro.developpez.com/cours/optimiser/

Voyons maintenant comment optimiserles 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. Celapermet 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 duserveur 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.
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://sqlpro.developpez.com/cours/optimiser/http://wiki.postgresql.org/wiki/Performance_Optimizationhttp://www.javalobby.org/articles/hibernatequery102/http://bmarchesson.developpez.com/tutoriels/java/hibernate/chargement/http://arodrigues.developpez.com/tutoriels/java/performance/hibernate-performance-part1-strategies-chargement/#LVII-Ahttp://sqlpro.developpez.com/cours/optimiser/http://wiki.postgresql.org/wiki/Performance_Optimizationhttp://www.javalobby.org/articles/hibernatequery102/http://www.javalobby.org/articles/hibernatequery102/http://java.developpez.com/faq/hibernate/?page=Criteriahttp://arodrigues.developpez.com/tutoriels/java/performance/hibernate-performance-part1-strategies-chargement/#LVII-Ahttp://bmarchesson.developpez.com/tutoriels/java/hibernate/chargement/http://bmarchesson.developpez.com/tutoriels/java/hibernate/chargement/http://docs.jboss.org/hibernate/stable/core/reference/fr/html/performance.htmlhttp://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


21/35




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 trejudicieux de placer les objets (indexes, tables...) souvent utiliss dans un ou plusieurs tablespaces sur les disquesdurs les plus rapides.

Plus d'informations surhttp://oracle.developpez.com/guide/architecture/tablespaces/
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://oracle.developpez.com/guide/architecture/tablespaces/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


22/35




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 sriede statistiques. Cela signifie qu'en fonction de divers paramtres (volumtrie, rpartition des donnes...) on aura unplan 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 dedonnes 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 machinede 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 afind'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 explainsur 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 joindb_order_item on db_order.id=db_order_item.order_id

where customer_id=4

donne
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://oracle.developpez.com/guide/tuning/statpack/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://oracle.developpez.com/guide/tuning/statpack/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


23/35




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 tablesParcours squentiel :Full Table ScansLa table est directement lue partir du disque dur et n'utilise ni le cache, ni aucun index....

Parcours d'index :Index Full ScanL'index est directement lu partir du disque dur et n'utilise pas le cache.

Fast Full Index ScanLa mme chose que Index Full Scan mais en plus rapide (la stratgie de lecture sur disque dur n'est pas la mme)....

ROWID ScanAccs direct un ensemble de tuples

JointureNested LoopsLorsque 2 tables sont jointes par Nested Loops, il y en a donc une qui boucle sur une autre.

Hash JoinUne table de hachage est cre pour la jointure....

Pour le SET AUTOTRACE ON

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


24/35




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 requteAvant 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 dejointure;

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 devaleurs 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'indexsoit 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 mauvaisniveau d'isolation, une table entire peut avoir un verrou alors qu'il pourrait tre sur seulement une ligne.

Par exemple sous PostgreSQL :


25/35




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 surhttp://sqlpro.developpez.com/cours/optimiser/

De mme il faut passer un peu de temps comprendre comment marche l'optimiseur de requte de la base dedonnes 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 ordredcroissant (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 pourraprendre le plus rapide ou le plus complet ou ...Aprs il faut vrifier que toutes les ressources (Connexions, Statements, ResultSets) sont bien fermes lorsqu'ellesne 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 deconnexion du serveur d'application. Ne pas oublier de changer la valeur du nombre de thread pour qu'elle soitsuffisante pour ouvrir assez de connexions.
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://sqlpro.developpez.com/cours/optimiser/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


26/35




Regardons un peu plus dans le code source de l'application. Reprons les Statements qui vont tre appels denombreuses fois et changeons-les par des PreparedStatement. L'avantage des instances PreparedStatement estqu'elles contiennent une instruction SQL dj compile.

Utilisation de PreparedStatementPreparedStatement 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 surhttp://java.developpez.com/faq/jdbc/?page=preparedstatement

Une autre astuce peut tre de regrouper les requtes dans un batch

Utilisation de batchConnection con = DriverManager.getConnection(.......);
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://java.developpez.com/faq/jdbc/?page=preparedstatementhttp://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


27/35




Utilisation de batchStatement 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 manuellesetAutoCommit(false);

// Executer toute les requtesExecuteUpdate();

On retrouvera ces conseils et d'autres surhttp://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 surmon 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 enoctets 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 surhttp://developer.yahoo.com/performance/rules.htmlOn peut utiliser le pluginYSlow 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 rcuprertous les rsultats si on n'affiche que 10 la fois. Il existe des frameworks pour cela comme HDPagination.
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://sourceforge.net/projects/hdpaginationhttps://addons.mozilla.org/en-US/firefox/addon/5369http://developer.yahoo.com/performance/rules.htmlhttp://arodrigues.developpez.com/tutoriels/java/performance/hibernate-performance-part1-strategies-chargement/http://www.precisejava.com/javaperf/j2ee/JDBC.htmhttp://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


28/35




Pour les applications en JSP avec beaucoup d'crans, il peut tre utile d'augmenter la taille mmoire de la zonePermanent 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 endveloppement pour ne pas avoir redployer l'application chaque modification de la JSP mais inutile enproduction.Pour gagner du temps, il suffit de modifier les valeurs false des paramtres development et reloading de la servletJasper dans le fichier Tomcat Home/conf/web.xml

web.xml

jsporg.apache.jasper.servlet.JspServlet

...

development

false

reloading

false

...

genStrAsCharArray.

De mme on peut forcer la gnration en char arrays de tous les static strings de la JSP. Cela vite l'utilisation detoCharArray() chaque fois.

web.xml

jsporg.apache.jasper.servlet.JspServlet

...

genStrAsCharArraytrue

...

Pool de Custom Tags.

Il est possible d'activer un pool pour l'utilisation des Custom Tags.
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


29/35




Pour l'activer, modifions la valeur true du paramtre enablePooling de la servlet Jasper dans le fichier TomcatHome/conf/web.xml

web.xmljsp

org.apache.jasper.servlet.JspServlet...

enablePooling

true

...

Il faut faire attention si on a de "grosses" JSP car on peut avoir une exception OutOfMemory. Si cela arrive (ou quelorsqu'on profile l'application, on se retrouve avec BodyContentImpl qui consomme beaucoup de mmoire), on peutparamtrer 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

ou dans l'interface d'administration du serveur d'application

IV-E - Problmes de thread

Les principaux problmes lis aux threads sont :


30/35




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 deconnexion 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 nombrede 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'avoiren 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 (tauxd'occupation processeur infrieur 80%) et de surcharger le serveur de bases de donnes.


31/35




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) afinde 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 GlassfishConfiguration -> HTTP Service -> HTTP Listeners -> http-listener-1Puis 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 valeurpar dfaut qui est de 1).


32/35




HTTP Request Processing Threads.

HTTP Request Processing Threads permet de grer les requtes HTTP entrantes.Dans la console d'administration de GlassfishConfiguration -> HTTP Service -> RequestProcessingPuis 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).


33/35




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 lesproblmes 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 passynchroniser 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 unesurconsommation 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 ArrayListSinon 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 HashMapSinon prfrer LinkedBlockingDeque, ArrayBlockingQueue, ConcurrentLinkedQueue, LinkedBlockingQueue ouPriorityBlockingQueue.

IV-F - Exception

Comme indiqu sur http://blog.developpez.com/adiguba/p1075/java/perfs/exception-et-performances/ lesexceptions sont coteuses mais indispensables. Par contre n'utiliser les exceptions que pour ce qu'elles ont tcres 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;
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://blog.developpez.com/adiguba/p1075/java/perfs/exception-et-performances/http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


34/35




Mauvaise utilisation des exceptions while (true) {

i = i +1;

thrownew FinAdditionException();

}

Pour reprer ce genre de mauvaise utilisation des exceptions, lors du profilage de la mmoire, vrifier le nombred'allocations d'objets Exception ou utiliser la fonction deYourkit 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 certainescouches 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 performancesde 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; ...
http://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://www.theserverside.com/news/thread.tss?thread_id=48449http://arodrigues.developpez.com/tutoriels/java/performance/audit-performance-avec-yourkit-java-profiler/#LIV-Ehttp://arodrigues.developpez.com/tutoriels/java/performance/audit-performances-application-java-ee/http://arodrigues.developpez.com/http://www.developpez.net/forums/u6300/ra77/http://www.developpez.com/


35/35


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 deperformance, 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 mfierdes "trucs et astuces" que l'on trouve sur le net (y compris cet article) car elles dpendent ducontexte 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 Milamberpour 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/HotSpotF

audit j2ee

Documents