Audit des performances d'une application en Java EE

Cela nous permettra de :

• trouver les fuites de mémoire ;
• réduire la consommation de la mémoire ;
• identifier rapidement les méthodes qui créent les objets.

Par exemple avec Yourkit Java Profiler.

Cela nous permettra de :

• découvrir les goulots d'étranglement  ;
• avoir des mesures par ligne d'instruction.

Par exemple avec Yourkit Java Profiler.

Cela nous permettra de :

• détecter les verrous mortels (dead lock) ;
• détecter les Conditions de course (Race conditions).

Par exemple avec Yourkit Java Profiler.

Avec le serveur d'application, souvent il y a un module de monitoring.
Cela nous permettra de :

• détecter si la taille des pools est correcte.

La plupart des bases de données ont un outil de monitoring. Par exemple, Oracle dispose de DB Console.
Cela nous permettra de :

• détecter les requêtes les plus lentes ;
• détecter les requêtes les plus utilisées ;
• tuner les paramètres du serveur de base de données.

Plus d'informations ici

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 scénarios et le nombre d'utilisateurs associés.
Par exemple, supposons que l'application doive tenir la charge de 100 utilisateurs simultanés 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 :

Plus d'informations ici.

II-B-1-c-i. Conception d'un scénario de test▲

Plus d'informations ici.

Pendant les tests de charge, afin de paramétrer l'application pour bien répartir les traitements et avoir le maximum d'utilisateurs en simultanée, 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 données :

  • taux d'occupation du pool de connexion ;
  • nombre de connexions en attente ;
  • taux d'occupation du processeur.

Le principe est de paramétrer le nombre de connexions/thread sur chaque serveur afin :

• d'avoir un taux d'occupation processeur inférieur à 80 % ;
• d'avoir un minimum de thread/connexions en attente ;
• d'avoir un taux d'occupation des pools le plus haut possible.

Pour cela il faut bien avoir en tête 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 données trop de requêtes et donc devra attendre qu'il les traite. Or avec cette surcharge de travail, le serveur de bases de données va traiter de moins en moins rapidement les demandes.(Dans ce cas, c'est donc la base de données qui sera le goulot d'étranglement de l'architecture.)

L'utilisation d'outils système (vmstat, mpstat, iostat, DTrace, Gestionnaire des tâches…) ou d'outils de monitoring pour surveiller un certain nombre de paramètres est une bonne idée.

Pour avoir les temps de réponse des requêtes/transactions échangés entre l'application et JMeter, les items listeners de JMeter le font très bien.

Par exemple avec Summary Report, on a les mesures intéressantes pour les temps de réponse :

• Average (ms) : moyenne des temps de réponse ;
• Min (ms) : valeur du plus petit temps de réponse ;
• Max (ms) : valeur du plus grand temps de réponse ;
• 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'arrêter.

Avant de commencer, il est important de savoir comment est gérée la mémoire 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 mémoire est composée de deux zones :

• la Heap : cette zone mémoire 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 réservée au chargement des classes. L'option XX:MaxPermSize permet de définir sa taille maximum.

La Heap est composée de deux zones :

• New Generation : c'est dans cette zone mémoire que sont alloués 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 durée de vie se retrouvent à un moment.

La New Generation est composée de deux zones :

• Eden

• Survivor. L'option XX:SurvivorRatio  permet de définir sa taille.

  • From
  • To

En plus des zones mémoire, il y a le GC (garbage collector) qui supprime de la mémoire les objets non utilisés (objets qui ne sont plus rattachés à la GC root).
Il existe deux types de GC :

• Minor GC : qui s'exécute rapidement et fréquemment sur la zone New Generation ;
• Major/full GC : qui s'exécute plus lentement (tous les processus sont arrêtés…) 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 mémoire Eden ;
• lorsque la zone Eden est pleine, un minor GC est exécuté et les objets vivants sont copiés dans From ;
• lorsque la zone From est pleine, un minor GC est exécuté et les objets vivants sont copiés dans To ;
• lorsque la zone To est pleine, les objets sont copiés dans Old Generation ;
• lorsque la zone Old Generation est pleine, un major/full GC est exécuté.

De ces explications, on peut en conclure qu'il faut minimiser les major GC. Pour cela il est important de :

• préférer les objets avec une courte durée de vie afin d'éviter de passer dans la zone Old Generation ;
• ajuster la taille de la zone Young Generation. SUN préconise que la taille de la zone Young Generation soit inférieure à 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 croître il faut un major GC) ;
• la taille maximale de la Heap (option -Xmx) doit être supérieure à sa taille minimale pour éviter les crashes ou égale pour plus de performance.

On peut aussi paramétrer le fonctionnement de la GC. Par exemple le paramètre -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 vérifier :

• l'utilisation de la Heap : taille utilisée, taille maximale… ;
• la fréquence de l'activité du GC ;
• le temps de l'exécution de la GC ;
• le type de GC exécuté.

Afin d'avoir des informations sur le GC, ajouter -verbose:gc, -XX:+PrintGCTimeStamps, -XX:+PrintGCDetails aux paramètres de la JVM

Pour avoir plus d'information sur la gestion de la mémoire par la JVM
https://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

Comme on l'a vu sur la partie fonctionnement de la mémoire, les objets de la fuite de mémoire ont de fortes chances de se trouver dans la zone mémoire Old Generation et donc afin de gagner du temps, on peut se concentrer sur cette partie.

Les deux problèmes majeurs viennent de la mauvaise utilisation :

• des objets en HTTP session ;
• des collections.

Il existe de nombreuses méthodes permettant de trouver une fuite mémoire. Mais avant de commencer, il est important de savoir qu'un OutOfMemoryError ne vient pas forcément d'une fuite de mémoire. Donc la première chose à faire est de bien paramétrer la configuration mémoire de la JVM.

II-C-2-b-i. Analyse de fuite de mémoire à partir de dump▲

Un dump est une copie de tout ce qu'il y a en mémoire de la JVM. De cette manière on peut savoir le nombre d'objets vivants, leurs consommations mémoire…

• On crée le dump.

Il existe plusieurs moyens.

En paramétrant 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 méthodes peuvent être utilisées.
Par exemple on peut comparer deux dumps (avant lancement du traitement et après le traitement) afin de visualiser les objets qui restent en mémoire après traitement.
Un autre point de départ est de repérer les objets qui consomment énormément de mémoire.
Une fois les objets choisis (quel que soit le point de départ), le principe est d'aller dans les détails jusqu'à trouver la fuite mémoire dans le code.

La mauvaise gestion des chaînes de caractères en Java peut engendrer une « surcréation » d'objets et une surconsommation de mémoire.

Par exemple :

• pour concaténer les chaînes de caractères, utiliser la classe StringBuffer/StringBuilder ;
• préférer String s = « MaChaineDeCaracteres » à String s = new String(« MaChaineDeCaracteres ») ;
• créer les chaînes de caractères avec la bonne taille (Findbugs peut vous y aider) ;
• …

Attention, car avec le compilateur JIT (Just In Time), cela n'est pas toujours nécessaire.

On peut détecter une mauvaise utilisation des chaînes de caractères de la manière suivante.

Pour cela on va partir de ce code :

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 près la mémoire

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'exécution est de 1.73 s

Maintenant, changeons le String en 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 a beaucoup moins d'allocations de Char[] en mémoire

Le temps d'exécution passe à 0.0036 s

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

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 mémoire reste identique, mais le temps d'exécution descend à 0.0034 s

Maintenant, initialisons le StringBuilder directement 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'allocations de Char[] diminue

Le temps d'exécution passe à 0.0034 s

Avec ces quelques conseils, on a réussi à diminuer :

• le temps d'exécution ;
• le nombre d'allocations de Char[] et donc les fréquences du fonctionnement du GC.

Et cela assez facilement en profilant la mémoire.

Comme vu précédemment, la création d'objets augmente la fréquence de déclenchement du GC. Et donc il faut éviter la création d'objets inutiles.

Par exemple :

• sortir si c'est possible la création d'objets des boucles ;
• utilisation de Integer.parseInt(s) à la place de Integer.valueOf(s).intValue() ;
• …

Il y a un certain nombre de règles 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.

Les frameworks de persistance sont pratiques, mais il faut faire attention à leur utilisation, car il y a beaucoup de choses qui sont « cachées ».

Nous allons nous focaliser sur Hibernate.

La première 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 paramètre hibernate.show_sql
Il est aussi possible d'activer les statistiques pour encore plus d'informations avec le paramètre hibernate.generate_statistics

Plus d'informations sur mon premier article sur Hibernate

Une fois cela fait, on va travailler sur deux parties, les clés primaires autoincrémentées et les stratégies de chargement. Et enfin on verra une manière de faire des recherches multicritères avec Hibernate.

Quelques conseils peuvent se trouver sur http://blog.octo.com/antipattern-hibernate/et http://www.javalobby.org/articles/hibernate-query-101/

N'hésitez pas à faire appel à un DBA si c'est possible.

II-C-2-e-i. Clés primaires autoincrémentées▲

II-C-2-e-ii. Les stratégies de chargement▲

II-C-2-e-iii. Recherche multicritère▲

Un pool de connexion permet de créer un certain nombre de connexions au démarrage du serveur d'application. Cela permet de ne pas créer de connexion (process qui est très 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 à deux choses afin de choisir le bon nombre :

• la charge processeur ne doit pas dépasser 80  % ;
• ce nombre dépend aussi du nombre de thread.

Un tablespace est l'espace de stockage où sont stockés les objets de la base de données.
Il faut bien définir les tablespace en les répartissant sur plusieurs disques durs si nécessaire. Par exemple il peut être judicieux de placer les objets (indexes, tables…) souvent utilisés dans un ou plusieurs tablespaces sur les disques durs les plus rapides.

Plus d'informations sur https://oracle.developpez.com/guide/architecture/tablespaces/

Afin de déterminer le meilleur plan d'exécution d'une requête, les serveurs de base de données utilisent une série de statistiques. Cela signifie qu'en fonction de divers paramètres (volumétrie, répartition des données…) on aura un plan d'exécution différent et que ce plan d'exécution pourra évoluer avec le temps.

Donc il est important que ces statistiques soient à jour. Pour cela il existe des outils spécifiques à chaque base de données comme Runstats sous DB2, DBMS_STATS sous Oracle et VACUUM sous PostgreSQL.

Il peut être utile de récupérer les statistiques de la base de données en production et de les mettre sur la machine de test afin de pouvoir reproduire les problèmes.

De nombreux outils permettent d'avoir un historique des requêtes exécutées par l'application.
Sous Oracle 10g il y a AWR (Automatic Workload Repository) et STATPACK.
Plus d'information sur STATPACK : https://oracle.developpez.com/guide/tuning/statpack/

Sous Oracle, on a aussi la vue système nommée 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'exécution ;
• fetches : nombre de lignes retournées ;
• buffer_gets : le nombre de block mémoire lus ;
• disk_reads : le nombre de block disque lus ;
• executions : le nombre d'exécutions ;
• rows_processed : le nombre de lignes traitées ;

Avec ces informations, on peut diagnostiquer un certain nombre de problèmes.

Pour MySQL, on peut lancer le serveur avec les options --log-slow-queries et --log-queries-not-using-indexes afin d'avoir les requêtes qui posent problème dans un fichier log.

II-C-3-d-i. Plan d'exécution d'une requête▲

Une fois les requêtes coûteuses détectées, 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 requête.
Cela nous permettra d'avoir le plan d'exécution de la requête afin de savoir comment elle se comporte exactement.
Par exemple, on pourra savoir si elle utilise un index et son coût.

• Voilà un exemple de l'utilisation  d'un EXPLAIN sous PostgreSQL.

Utilisation de Explain sous PostgreSQL

Sélectionnez

select * from db_order join db_order_item on db_order.id=db_order_item.order_id
where customer_id= 4

donne

Résultat de Explain

Sélectionnez

"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 manière visuelle

Afin de pouvoir étudier le résultat il faut savoir que :

Accès aux données des tables
Parcours séquentiel :
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 même chose que Index Full Scan, mais en plus rapide (la stratégie de lecture sur disque dur n'est pas la même).
…
ROWID Scan
Accès direct à un ensemble de tuples

Jointure
Nested Loops
Lorsque deux tables sont jointes par Nested Loops, il y en a donc une qui boucle sur une autre.
Hash Join
Une table de hachage est créée pour la jointure.
…

• Pour le SET AUTOTRACE ON

Recursives calls : une instruction SQL appelle d'autres requêtes SQL.
Consistents gets : lecture dans le cache de Oracle.

II-C-3-d-ii. Index▲

II-C-3-d-iii. Délais d'attente▲

S'il y a un gros écart entre le cpu_time et le elapsed_time, c'est qu'il y a des délais d'attente qui peuvent être divers (accès disques, verrous…).
Pour les verrous, vérifier si le niveau d'isolation est correct afin d'en éviter le maximum. Par exemple avec un mauvais niveau d'isolation, une table entière 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 requête SQL pour bloquer une ligne

  • SELECT 1 FROM table1 WHERE id_table1 > 5 FOR UPDATE;

Une solution plus générique est d'utiliser les fonctions setTransactionIsolation() de l'interface Connection.

Utilisation de setTransactionIsolation()

Sélectionnez

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

Pour éviter les délais dus au réseau, il peut être utile :

• d'utiliser des procédures stockées ;
• minimiser les datas retournés par les requêtes (éviter les Select * from …) ;
• utiliser des caches ;
• …

Pour diminuer les accès disque, il peut être utile de :

• ajouter des index ;
• augmenter le paramètre mémoire du SGBD (SGA/PGA pour Oracle…) ;
• prendre une machine plus puissante ;
• …

II-C-3-d-iv. Optimisation des requêtes SQL▲

Maintenant que les requêtes, le schéma et le serveur ont été optimisés, il est temps de passer au niveau JDBC.

La première 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 …
Après il faut vérifier que toutes les ressources (Connexions, Statements, ResultSets) sont bien fermées lorsqu'elles ne sont plus utilisées. Pour cela on peut utiliser PMD/Findbugs en complément d'une revue de code.
Une fois cela fait il faut choisir le bon nombre de connexions possibles qu'il faudra paramétrer 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. Repérons les Statements qui vont être appelés de nombreuses fois et changeons-les par des PreparedStatement. L'avantage des instances PreparedStatement est qu'elles contiennent une instruction SQL déjà compilée.

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

Une autre astuce peut être de regrouper les requêtes dans un batch

Connection con = DriverManager.getConnection(.......);
Statement stmt = con.createStatement();
stmt.addBatch("INSERT INTO Adresse .......");
stmt.addBatch("INSERT INTO Contacte .......");
int[] countUpdates = stmt.executeBatch();

ou de regrouper les requêtes dans une transaction de la manière suivante :

setAutoCommit(false);
// Executer toute les requêtes
ExecuteUpdate();

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

Il est important de configurer Hibernate finement et d'utiliser des jointures afin d'éviter trop de requêtes. Pour plus d'informations, reportez-vous à la partie consommation mémoire et sur mon article sur Hibernate

• JSP Reload et JSP Development Mode.

Si l'application est en production, on peut désactiver un certain nombre d'étapes du cycle de vie d'une JSP

Par exemple à chaque requête pour une JSP, Tomcat vérifie si cette JSP a été modifiée. Cela est très utile en développement  pour ne pas avoir à redéployer l'application à chaque modification de la JSP, mais inutile en production.
Pour gagner du temps, il suffit de modifier les valeurs à false des paramètres development et reloading de la servlet Jasper dans le fichier Tomcat Home/conf/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 même on peut forcer la génération en char arrays de tous les static strings de la JSP.  Cela évite l'utilisation de toCharArray() à chaque fois.

<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 paramètre enablePooling de la servlet Jasper dans le fichier Tomcat Home/conf/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 mémoire), on peut paramétrer dans le fichier de démarrage de Tomcat :

• org.apache.jasper.runtime.JspFactoryImpl.USE_POOL = false
• org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER = false
• Désactiver l'AutoDeploy.

Lorsque Tomcat trouve un nouveau WAR dans son répertoire webapps, il le déploie automatiquement.
Pour désactiver cette fonction, il faut modifier le fichier Tomcat Home/conf/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

La 1re chose à faire si cela n'a pas déjà été fait est de vérifier le taux d'occupation du pool de thread et le nombre de thread en attente.
En fonction de ces deux 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 départ).

Il faut bien faire attention à ne pas mettre un nombre trop grand sous peine de surcharger la machine (taux d'occupation processeur inférieur à 80  %) et de surcharger le serveur de bases de données.

Comme on l'a déjà vu, il faut paramétrer 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 ;
• gérer les nouvelles requêtes associées aux connexions existantes.

Dans la console d'administration de Glassfish
Configuration -> HTTP Service -> HTTP Listeners -> http-listener-1
Puis mettre la bonne valeur dans « Acceptor Threads »
Il est recommandé de mettre 1 Thread pour 1 à 4 cœurs (donc sur un dual core, pas besoin de changer la valeur par défaut qui est de 1).

• HTTP Request Processing Threads.

HTTP Request Processing Threads permet de gérer les requêtes HTTP entrantes.
Dans la console d'administration de Glassfish
Configuration -> HTTP Service -> RequestProcessing
Puis mettre la bonne valeur dans « Thread Count »

Certaines options de la JVM permettent d'améliorer les performances.

Par exemple l'option -XX:+UseBiasedLocking de la JVM de Sun (à partir de JDK 5.0_06 et activer par défaut dans JDK 6).

D'un point de vue code source, s'il n'y a pas de problème d'algorithme, les deux principaux moyens de réduire les problèmes de threads sont :

• minimiser le périmètre des blocs synchronisés ;
• utiliser des objets non synchronisés (ArrayList, StringBuilder…).

II-C-5-d-i. Blocs synchronisés▲

II-C-5-d-ii. Objets non synchronisés▲