Tests de performances d'une application Java EE

Tests de performances d'une application Java EE Tours JUG – 10 juin 2010 Antonio Gomes Rodrigues

Sponsors

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

Mesurez, ne supposez pas

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

Une application fonctionnelle

Sommaire ● Procédure de test ● Définition de la stratégie de test ● Faire un test de charge ● 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 ● Procédure de test ● Définition de la stratégie de test ● Faire un test de charge ● Quand faire un test de charge ● Quoi mesurer/vérifier ● Quand donner les résultats ● Que va t on trouver ● Procédure ● Rapport d'audit

Quand faire un test de charge

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 ● Procédure de test ● Définition de la stratégie de test ● Faire un test de charge ● Quand faire un test de charge ● Quoi mesurer/vérifier ● Quand donner les résultats ● Que va t-on trouver ● Procédure ● Rapport d'audit

Quoi mesurer/vérifier

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, ...)

Paramétré pour la prod

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>

Niveau de log

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

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

S'adapter à son auditoire

Identifier les problèmes

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

Diag Java EE

Diag mémoire

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

Diag mémoire

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 ● Exception in thread "main": 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 ● Exception in thread "main": 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 ● Exception in thread "main": 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 ● Exception in thread "main": 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 CPU

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

http://www.developpez.net	41
http://www.slideshare.net	3
http://static.slidesharecdn.com	1
http://java.developpez.com	1

Tests de performances d'une application Java EE

by Antonio Gomes Rodrigues

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 46

Statistics