Tests de performances d'une application Java EE

Tests de performances d'une
application Java EE

Tours JUG – 10 juin 2010

Antonio Gomes Rodrigues

Antonio Gomes Rodrigues
● Consultant en performances JavaEE
● Plus de 6 ans d'expériences
● Rédacteur sur developpez.com
● http://arodrigues.developpez.com/

Des ressources Des actualités

http://twitter.com/javaDeveloppez

java@redaction-developpez.com

De l'entraide Un hébergement gratuit
w w
:/ /w
http

Commencez par faire correctement les choses,
puis accélérez-les si cela ne va pas assez vite

Sommaire
● Procédure de test
● Définition de la stratégie de test
● Faire un test de charge
● Identifier les problèmes
● Diagnostic Java EE

Procédure de test
● Itératif
● Préparer les tests
● Mesurer les performances
● Identifier les problèmes
● Corriger les problèmes (faire seulement une
modification à la fois)
● Recommencer jusqu'à atteindre les objectifs

Définition de la stratégie de test

Définir les objectifs de l'audit de
performance
● Résoudre des problèmes de performance d'une
application,
● Dimensionner une infrastructure de production pour un
déploiement national,
● Rassurer la DSI sur la montée en charge d'une
application
● Valider les performances/endurance/robustesse d'une
application,
● Comparer des solutions,
● ...

Identifier les scénarios pertinents et
les pondérer
● Des scénarios réalistes (écrans consultés, champs
saisis dans les formulaires, temps entre chaque
actions, ...).
● Faire les scénarios importants (ceux de tous les jours
mais aussi ceux importants d'un point de vue
fonctionnel (déclenchement de la paye, ...))
● Voir les logs d'accès, cas d'utilisation, ...
● Attention au cas où l'application fait appel à un service
extérieur (serveur de cartographie, serveur de
validation du numéro de carte bleue, ...).

Identifier les outils et les ressources
à disposition
● Outils mis à disposition (LoadRunner, JMeter,
Introscope, ...)
● Disponibilité des développeurs, fonctionnels, DBA,
administrateur système, ...
● S'assurer de la disponibilité exclusive de
l'environnement

S'assurer que la plateforme testée
est la plus proche possible de la
plateforme cible

S'assurer que la plateforme de test
répond aux exigences du test

S'assurer d'avoir un jeux de
données réaliste

● Données de prod, ETL, Outils spécifique
(Benerator, ...)

Démo de Benerator
● Plugin pour Maven2
● Plugin pour Eclipse
● Personnalisable
● Gratuit
● Bonne documentation
● Supporte la majorité des bases de données du
marché
● http://databene.org/databene-benerator

Identifier les métriques à collecter

Sommaire
● Quand faire un test de charge
● Quoi mesurer/vérifier
● Quand donner les résultats
● Que va t-on trouver
● Process
● Rapport d'audit

Sommaire
● Que va t on trouver
● Procédure
● Rapport d'audit

Demo de ContiPerf

● Simple d'utilisation
● Intégration à Maven2
● Intégration à Eclipse
● Export des résultats au format CSV
● …
● http://databene.org/contiperf.html

Demo de Yourkit Java Profiler

● Une grande richesse fonctionnelle
● Intégration aux principaux IDE du marché
● Multi plate-forme
● Intégration aux principaux serveurs
d'application
● Contrôle de l'overhead pour s'adapter à la
machine cible
● http://www.yourkit.com/overview/index.jsp

Quand faire un test de charge
● En fin de projet
● Pour :
● Régler les serveurs
● Augmenter les performances
● Valider la mise en production,
● ...

Sommaire
● Que va t-on trouver
● Procédure
● Rapport d'audit

Sur chaque serveur
● L’activité du système
● L’activité du réseau (débit, taux de perte, ...)
● L’occupation mémoire (mémoire occupée,
mémoire libre, mémoire swap, ...)
● L’occupation du processeur (taux
d'occupation, ...)

Sur chaque JVM
● JVM Mode
● Vérifier qu'on est bien en "-server"et non en "-client" (En
particulier sur les JVM 1.4 et inférieur)
● Taille de la Java Heap
● La taille de la heap (Java options -Xmx (maximum) et
-Xms (minimum)) et son comportement.
● Comportement du Garbage Collection
● Sa fréquence, son temps d'exécution, ... (-verbose:gc,
-XX:+PrintGCTimeStamps, -XX:+PrintGCDetails)
● Dump mémoire
● -XX:+HeapDumpOnOutOfMemoryError
● -XX:+HeapDumpOnCtrlBreak

Sur les serveurs d'application
● L’activité du système
● L’activité du réseau (débit, taux de perte, ...)
● L’occupation mémoire (mémoire occupée,
mémoire libre, mémoire swap, ...)
● L’occupation du processeur (taux
d'occupation, ...)

Désactiver l'Auto-Deploy

Tomcat - conf/server.xml
<Host name="localhost" appBase="webapps" unpackWARs="true"
autoDeploy="false"
xmlValidation="false" xmlNamespaceAware="false">

JSP Reload et
JSP Development Mode
Glassfish - default-web.xml
<init-param>
<param-name>development</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>genStrAsCharArray</param-name>
<param-value>true</param-value>
</init-param>

Pool de connexion JDBC

● Taille du pool
● Maximum wait time
● Average wait time
● Minimum available free connections

Pool de threads

● Taille du pool
● Taux d'occupation du pool de thread
● Le nombre de threads en attente

Web Container

● Nombre maximal de connexions ouvertes
● Pool d'unité d'exécution
● Le cache (surtout pour les objets statiques)

EJB Container

● Taille du pool de thread
● Taille du cache
● Taille du pool Message Driven Beans

Sessions

● Nombre de sessions
● Délai d'expiration

Sur les serveurs de bases de
données

Taille mémoire cache
update TABLE_A_MODIFIER
set FIELD1 = FIELD1 + 1, FIELD2=' ' where (FIELD3>0)

Après tuning du cache

Les requêtes couteuses

● Attention, il faut bien paramétrer la taille de la
mémoire cache avant.
● MySQL propose un « slow query log »
● Oracle propose une vue
● Sinon plusieurs outils proposent de le faire

Autres
● Hibernate
● Activer ou désactiver le mode trace
d'hibernate
● Application
● Les fonctions les plus consommatrices.

Quand donner les résultats
● Au fur et à mesure car généralement cela induit
des décision importantes dont le cycle de
décision peut être relativement long.

● par exemple lancer des procédures d'achat de
matériel lors d'un dimensionnement
d'infrastructure, commander l'intervention d'une
expertise externe/interne, migration vers une
version plus récente de la librairie.

Que va t-on trouver
● Des mauvaises pratiques de conception ou de
développement,
● Une architecture logicielle qui ne privilégie pas les
performances,
● Un hardware sous dimensionné,
● Un mauvais paramétrage du serveur d'applications,
● Un mauvais paramétrage du serveur de bases de
données,
● Un mauvais paramétrage des frameworks (hibernate, ...)
● Problème d'utilisation de cache,
● ...

Procédure
● Capture scénario
● Paramétrage scénario
● Corrélation, variabilisation, think time, ...
● Regroupement dans un plan de test
● Paramétrage du plan de test
● Faire un tir unitaire/de référence
● Permet d'étalonner les scénarios et de collecter des temps de
réponse nominaux
● Exécuter le scénario
● Le tir doit être assez long pour monter en charge et obtenir des
moyennes significatives
● Récupérer les metrics
● Faire un rapport d'audit

JMeter - enregistrement d'un script

JMeter – exécution d'un script

JMeter Demo
● Bonne documentation
● Open Source et gratuit
● De nombreux protocoles supportés
● …
● http://jakarta.apache.org/jmeter/

Rapport d'audit
● C’est un long travail de consolidation de toutes les
informations pertinentes.

Mauvaise performances et
utilisation CPU élevée

Mauvaise performances et
utilisation CPU basse

Performances irrégulière et
utilisation CPU irrégulière

Mauvaises performances et
utilisation des I/O haute

Consommation mémoire élevée

Tuning
● Attention , la taille de la heap ne doit pas
dépasser la taille mémoire physique de la
machine.

● Il peut être utile de mettre la même valeur pour
-Xmx (maximum) et -Xms (minimum) afin
d'éviter les redimensionnement de la heap.

● Attention lorsque il y a beaucoup de JSP

Vérification des
paramètres

● Utiliser YourKit Java Profiler ou VisualVM ou ...

OutOfMemoryError
● Exception in thread "main":
java.lang.OutOfMemoryError: Java heap space
● Problème de paramétrage de la taille de la
heap
● Fuite mémoire

● Paramètre JVM : -Xmx
● Profiler/Dump

OutOfMemoryError
java.lang.OutOfMemoryError: PermGen space
● Beaucoup de classes
● Beaucoup d'objets String (String.intern ou
ClassLoader.defineClass dans la stack trace)

● Paramètre JVM : -XX:MaxPermSize
● jmap -permgen

OutOfMemoryError
java.lang.OutOfMemoryError: Requested array
size exceeds VM limit
● Utilisation de tableaux trop grands par
rapport à la taille de la heap

● Paramètre -Xmx
● Profiler/Dump

OutOfMemoryError
java.lang.OutOfMemoryError: request <size>
bytes for <reason>. Out of swap space?
● Fuite mémoire
● Serveur trop chargé en mémoire (autres
applications, ...)

● Profiler/Dump
● Monitoring du serveur

OutOfMemoryError
java.lang.OutOfMemoryError: <reason> <stack
trace> (Native method)
● Problème mémoire détecté lors d'une
interaction avec une application native à
l'aide de JNI

● Profiler/Dump
● Monitoring du serveur

Le coût du GC
● Si le temps utilisé par GC est supérieur à 25%
c'est qu'il y a un problème.
● Heap trop petite
● Trop d'objet
● Profiler/Dump
● Paramètre JVM : -Xmx
● Findbugs/PMD
● Modification de la stratégie du GC
● Pas d'appels explicite du GC :
-XX:-DisableExplicitGC

Diag Bdd
● Faire intervenir un DBA si nécessaire

Utiliser des index
update TABLE1 MxT3 set (T1.FIELD1) = (select T2.FIELD1 from TABLE2 T2
where (T1.FIELD2 = T2.FIELD3 )) where exists (select 1 from TABLE2 T2
where (T1.FIELD2 = T2.FIELD3 ))

Après
create index TABLE2_N98
on TABLE2 (FIELD3,FIELD1)

Limiter au maximum les
valeurs récupérées
● Pas de select *
● Conditions dans la clause where

Utiliser des Prepared
Statements
● Seulement pour les requêtes appelées de
nombreuses fois
PreparedStatement pstmt = con.prepareStatement("UPDATE
table SET i = ? WHERE j = ?");
pstmt.setLong(1, 123);
pstmt.setLong(2, 100);

Paramétrer le cache Prepared
Statements dans le serveur JavaEE
et/ou dans le driver JDBC

Éviter les commits trop
fréquents
setAutoCommit(false);
// Executer toute les requêtes
ExecuteUpdate();

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

Paramétrer le pool de
connexion JDBC
● Trouver la bonne taille lors des tests (regarder
le nombre de connexions en attente, la charge
CPU, ...).

Pour éviter la création de connexions
au mauvais moment, on peut fixer la
même valeur pour le min et le max

Libérer les ressources JDBC
● Libérer les ressources JDBC dans la clause
finally du try catch
● Utiliser Spring Jdbc template
● Utiliser Commons DbUtils

Findbugs

Diag thread
● Dead lock
● Au moins 2 threads se bloquent pour accéder à une
ressource.

● Race conditions
● Au moins 2 threads entrent en compétition pour
obtenir une ressource et donc le nombre de threads
augmente et il faut de plus en plus de temps pour
accéder à la ressource.

Diag thread
● Thread Leak
● On crée des thread sans fin jusqu'à avoir un
OutOfMemory: unable to create new native thread.

● Problème de configuration du pool de thread
● Le nombre de thread configuré dans le pool est
supérieur au nombre maximum de thread de la
JVM

Diag HTTP
● Une gestion des dates d'expiration sur les
ressources statiques couplée à un cache au
niveau des frontaux http pour soulager
l'infrastructure.
● Par exemple une image qui ne change pas
régulièrement peut avoir une date d'expiration
lointaine afin qu'à chaque requête, il n'y ait pas
de vérification sur l'existence d'une nouvelle
version.

Session
● Attention au volume des données stockées en
session car cela peut provoquer une
dégradation significative des performances
dans le cas notamment où la réplication de
session est activée.

Diag affichage
● Compression des ressources statiques
(images, fichiers flashs, scripts, ...)
● Mettre en place une politique d'expiration des
ressources statiques,
● Activer la compression HTTP
● Utiliser des CSS sprite
● CSS en début de page
● Javascript en fin de page

Diag Hibernate
● Optimisation du mapping hibernate pour réduire
significativement le nombre de requêtes
exécutées sur la base de données.
● Mes préconisations sont :
● D'initialiser les relations en mode différé (par
défaut)
● Puis au cas par cas s'assurer que ce mode de
chargement ne génère pas les problèmes dits de
N+1 ou les produits cartésiens.
● Optimiser les modes de chargement en utilisant les
techniques de chargement groupé, chargement par
sous select, etc.

Conseils
● Commencer les tests dès que possible
● Automatiser le maximum de tests
● Faire intervenir un DBA
● Faire de l'itératif
● Ne faire varier qu'un paramètre à la fois
● Communiquer
● ...

Tests de performances d'une application Java EE

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Tests de performances d'une application Java EE

Similaire à Tests de performances d'une application Java EE (20)

Plus de Antonio Gomes Rodrigues

Plus de Antonio Gomes Rodrigues (6)

Tests de performances d'une application Java EE