Tests de performances

Performance ? Méthodologie Outils Optimisation

Tests de performances

Damien Raude-Morvan

Université de Nantes, Département informatique

2012-2013

Tests de performances Damien Raude-Morvan 1/66


Table des matières

1 Performance ?

2 Méthodologie

3 Outils

4 Optimisation



Table des matières

1 Performance ?ProblématiqueTypes de tests

2 Méthodologie

3 Outils

4 Optimisation



Problématique

Table des matières


2 Méthodologie

3 Outils

4 Optimisation



Problématique

Analyse de la performance

L’analyse de la performance d’un système à pour but de s’assurerque ce dernier :

réalise de façon effective et pertinente (les bonnes choses) ;réalise de façon efficiente (rapidement, au bon moment, aumoindre coût) ;produit les résultats fixés ou attendus ;répond aux besoins et aux attentes des clients del’organisation ;



Problématique

Pourquoi tester ?

Learn to live with unpredictable behaviorLes architectures d’aujourd’hui sont devenues trop complexes pourque nous puissions préjuger d’un résultat en termes de QoS sanstester concrètement

Voir la présentation de Joshua Bloch (« Performance Anxiety ») :http://www.parleys.com/#st=5&id=2103&sl=2


http://www.parleys.com/#st=5&id=2103&sl=2


Problématique

Connaitre sa problématique

Les tests de performances peuvent servir des buts très différents :Contrôle qualité, Marketing

Quels sont nos temps de réponses ?Sommes-nous conformes au SLA « Service Level Agreement » ?Sommes-nous comparables ou mieux que nos concurrents ?

ConceptionLes dernières évolutions livrées ont-elles impacté lesperformances ?

Production / IntégrationCombien de serveur faut-il commander pour la chargeattendue ?



Problématique

Ratio coûts / gains

Coûts

Développement desscénarios de testsMise en place d’uneplate-forme dédiéeRéalisation de la campagnede tests et analyse desrésultats

Gains

Eviter l’affectation deressources imprévues dansl’urgenceEviter des pertes de revenuou des dégradations d’image



Types de tests

Table des matières


2 Méthodologie

3 Outils

4 Optimisation



Types de tests

Test de charge

Load testingSimuler un nombre d’utilisateursvirtuels prédéfinis, afin de validerl’application pour une chargeattendue d’utilisateurs.

Variation des paramètresNombre d’utilisateurs effectuantun certain nombre d’opérationsur une durée donnée.

Objectif / Résultat

Temps de réponse del’application sur les transactionscritiques. Avec les bonsindicateurs, permet de détecterdes goulots d’étranglement.



Types de tests

Test de dégradations des transactions

Isolation testingSimuler l’activité transactionnelled’un seul scénario fonctionnel dupérimètre

Variation des paramètresLancement d’un ensemble réduitd’actions utilisateurs.


Permet d’isoler éventuellementles transactions qui dégradent leplus fortement un système.



Types de tests

Test de stress

Stress testingSimuler une activité maximalesupérieure aux heures de pointede l’application.

Variation des paramètresAugmentation significative etrégulière du nombre d’utilisateurs


Permet d’évaluer lecomportement du système endehors modèle d’usage standard(robustesse) ou la charge limiteque le système est capable desupporter (capacité).



Types de tests

Test de d’endurance / de fiabilité

Endurance testing (soak testing)

Simuler une charge importanted’utilisateurs sur une duréerelativement longue.

Variation des paramètresAugmentation significative de ladurée du test (>= dizainesd’heures).


Permet de détecter des fuitesmémoires ou des consommationsexcessives de ressources.



Types de tests

Test aux limites

Spike testingSimuler l’augmentation rapide dunombre d’utilisateurs, pour voircomment le système réagit auxlimites du modèle d’usage del’application

Variation des paramètresAugmentation significative etsoudaine du nombre d’utilisateurs


Permet d’analyser lecomportement de l’applicationdurant et surtout après une fortecharge (retour à la normale)



Types de tests

Test de configuration

Configuration testingPlus que de mesurer laperformance brute, il s’agit decomparer la performance entredeux paramétrages différents del’application

Variation des paramètresReconfiguration de l’applicationentre chaque test (un seulparamètre)


Permet d’évaluer l’impact positif/ négatif de chaque paramètre



Table des matières

1 Performance ?

2 MéthodologieIdentifier l’environnement de testIdentifier les critères d’acceptationPréparer et concevoir les scénarios de testConfigurer l’environnement de testExécuter les tests et collecter les résultatsAnalyser, optimiser et rejouer les tests

3 Outils

4 OptimisationTests de performances Damien Raude-Morvan 16/66


Méthodologie

Liste des étapes de préparation et de réalisation d’un test :1 Identifier l’environnement de test2 Identifier les critères d’acceptation3 Préparer et concevoir les scénarios de test4 Configurer l’environnement de test5 Implémenter les scénarios6 Exécuter les tests et collecter les résultats7 Analyser, optimiser et rejouer les tests



Identifier l’environnement de test

Table des matières

1 Performance ?


3 Outils




Décrire le système à tester

Connaitre précisemment le périmètre des tests :Les composants testés en charge (front, back, stockage)Les parties de l’application testées (pages)Les dépendances entre les différents sous-systèmes(architecture SOA ?)

EssentielSans connaitre l’application et les composants, il est impossible defaire une campagne de tests !




Connaitre son architecture cible

Y a-t-il des contraintes d’architecture qui influent sur lecomportement de l’application à tester ?

Load-Balancer ?Cache distribué ?Equipement réseaux ?Espace de stockage ?

EssentielAvoir un environnement de test identique à la production etautonome (sans autres tests).



Identifier les critères d’acceptation

Table des matières

1 Performance ?


3 Outils




Choisir ses objectifs

On peut définir quatre types d’objectifs :Concurrence d’accès / débit Nombre maximal d’utilisateurs qui

peuvent être connectés au système à un instant t.Temps de réponse Mesure le temps de réception d’une réponse

entre deux points de l’application (client vers front,front vers middleware, middleware vers SGBD...)

Temps d’affichage Difficile à mesurer. Dans le cas d’uneapplication web, temps avant que l’utilisateur puisseeffectuer une action sur la page HTML.

Resources utilisées Pour un nombre d’utilisateur donné,consommation CPU/disque/réseau.




Définir ses critères d’acceptation

En théorieLes critères choisis doivent être documentés avant la conception.

En pratiqueCes critères n’ont pas été définis à l’avance et sont évalués enurgence avant une livraison.

Temps de réponse problématique du point de vue utilisateurConcurrence d’accès / débit problématique du point de vue

fonctionnelUtilisation des resources problématique du point de vue système /

production




Trouver le bon mix

Quelles sont les pages les plus consultées ?Définir des typologies d’utilisation de l’application (parrapport au profil utilisateur : 20% login, 40% recherche, 30%détails, 10% commande)Choisir la répartion de chaque typologie dans le test global(30% Managers, 20% Editeurs, 50% Consulation)

Essentiel

Optimiser ses scénarios pour obtenir une utilisation réaliste del’application.Spécifier la valeur nomimale et la valeur maximale



Préparer et concevoir les scénarios de test

Table des matières

1 Performance ?


3 Outils




Définir des scénarios 1/2

Documenter pas à pas chaque click, saisie, etc...Toujours commencer par un scénario simplifié afin de validerglobalement la cohérence de l’infrastructure (warm test)Vérifier que le scénario enregistré couvre bien les mêmesactions que sa documentation

EssentielChaque étape du scénario doit être précisemment décrite afin depermettre sa reproduction à l’identique.




Définir des scénarios 2/2

Penser à rendre le scénario variabilisable (différents comptesutilisateurs, profils, produits)Ajouter de l’aléa dans le déroulement (temps d’attente entrechaque page)Découper le scénation afin de pouvoir le réutiliser

EssentielL’objectif n’est pas (plus ?) d’effectuer la recette fonctionnelle del’application




Préparer des données de tests 1/2

Plus que les scénarios, le véritable challenge concerne les donnéesde tests. Il faut de la volumétrie :

Un test de charge sur une base de données presque vide n’aaucun sensDans la vraie vie, la base de données de votre application varapidement se remplir




Préparer des données de tests 2/2

Dans le même temps, il faut des données cohérentes :Avoir assez de diversité dans ses données pour permettre lestests.Revenir à un état "propre" à la fin de tests Indempotent Tests.



Configurer l’environnement de test

Table des matières

1 Performance ?


3 Outils




Mesurer, mesurer, mesurer 1/2

Mettre en place des agents de mesures sur chaquesous-systèmeVérifier que les métriques mesurées sont validesConnaitre l’impact des agents de mesures sur les performancesPrivilégiez la réalisation de calculs à posteriori plutôt quedurant le test

EssentielSans outils de monitoring de la plateforme cible, un test deperformance ne sert à rien !




Mesurer, mesurer, mesurer 2/2

Quelques métriques essentielles à surveiller :

Métriques

L’activité du système (load average)L’activité du réseauL’activité et l’occupation des disquesL’occupation mémoireL’occupation du processeur (en %)

EssentielIl faut bien connaitre la signification de chaque métrique !



Exécuter les tests et collecter les résultats

Table des matières

1 Performance ?


3 Outils



Exécuter les tests et collecter les résultats

Vérification de cohérence du tir

Une fois la campagne de tests terminée, avant de poursuivre il fautvérifier

Les métriques renvoyées par les agents de mesures par rapportaux limites du systèmeLe niveau d’erreur du point de vue applicatifLe niveau d’erreur du point de vue de l’outil de tests

Préparer...Il est souvent nécessaire de lancer plusieurs tests unitaires afin devérifier ses paramètres sur un périmètre réduit.



Analyser, optimiser et rejouer les tests

Table des matières

1 Performance ?


3 Outils




Comprendre les résultats

Trouver les patterns d’utilisation qui entraine un dépassementde critères d’acceptationCorréler les mesures de temps de réponses et les métriquesenregistrées sur le serveurDécouper le scénario de test et le reproduire jusqu’àdéterminer précisemment le composant incriminé (idéalementsur la même plateforme)




Restituer les résultats 1/2

Rédaction d’un rapport de résultats qui contient :une consolidation des métriques (courbes et tableaux)des alertes et des diagnosticsune comparaison avec la campagne N-1




Restituer les résultats 2/2

Attention à deux biais importants :Biais d’interprétation

L’utilisation de la moyenne masque des temps de réponses pluslongsPréférer l’utilisation d’un quantile (90%)Attention au temps de réponse des erreurs qui peuvent être àzéro

Biais de perceptionSur les graphiques, attention à l’échelle et l’origine de l’axe desabscisses.Attention également au lissage des courbesFaire le bon choix de couleurs



Table des matières

1 Performance ?

2 Méthodologie

3 OutilsPour mesurer la consommationPour jouer des scénariosPour comprendre

4 Optimisation



Choisir les bons outils



Pour mesurer la consommation

Table des matières

1 Performance ?

2 Méthodologie


4 Optimisation




VisualVM

Cet outil peut être utilisé à la fois en phase de développement etde production.

Permet de proposer une vue graphique sur les outils mis àdisposition par la JVMPermet de prendre des captures mémoires (Heap Dump)Graphiques sur l’utilisation mémoire, CPU, les threadsMétriques sur le comportement du Garbage Collector de laJVMPropose des plugins pour "aller plus loin"




Munin et autres outils système

Munin est un logiciel écrit en Perl capable de collecter des donnéessur différentes machines.

Il permet de mesurer beaucoup d’indicateurs (charges cpu,ram, réseau, espace disques ...)Il dispose d’une large communauté qui développe des pluginscomplémentaires (Oracle, NFS, MySQL...)Il permet de centraliser vers un seul et unique serveur les statsLes statistiques sont consultables via une simple page web

Exemple : http://munin.ping.uio.no/


http://munin.ping.uio.no/


Pour jouer des scénarios

Table des matières

1 Performance ?

2 Méthodologie


4 Optimisation




JMeter : présentation

Un outil assez complet et libre :Outil sous licence Apache 2.0Permet d’utiliser différents protocoles (HTTP, SOAP, LDAP,FTP)Permet d’enregistrer des scénarios via un système de proxyHTTPPas d’outils de monitoring et assez peu de rapports

Paradigme1 thread = 1 utilisateur




JMeter : concepts

Test plan contient le scénario de test (enregistré sur disquedans un format XML)

Workbench est une zone de travail temporaire non persistéeThread Group représente un pool d’utilisateurs

Sampler représente la description d’une requête effectuée versle serveur

Logic Controller permet d’ajouter une surcouche de logique etainsi un ordre aux Samplers

Listener permet de visualiser, sauver ou lire les mesures dutest




JMeter : interface

Voici un exemple de scénario de test simpliste qui contient un seulThread Group.

IHM...Il est possible d’utiliser entièrement JMeter sans IHM (et ainsid’obtenir de meilleures performances)




Gatling : présentation

Outil sous licence Apache 2.0Plutôt que d’utiliser un format de stockage XML, avec Gatlingle test est également du code (Scala)Propose un DSL afin de décrire les actions à réaliser par lescénarioDispose également d’un "Recorder" qui permet d’utiliser unproxy HTTP depuis son navigateur

ParadigmeUtilisation du pattern Actor (via Akka) (donc 1 thread != 1utilisateur)




Gatling : concepts

Scenario un ensemble d’instruction à suivre (décrites via leDSL)

Simulation contient plusieurs scénarios, avec pour chacun lenombre d’utilisateur

Feeders classe qui permet d’injecter des données dans lescénario

Checks description des tests que doit effectuer Gatling afinde déterminer qu’une instruction est OK




Gatling : exemple

Voici un exemple de scénario avec Gatling

class SimulationWithFollowRedirect extends Simulation { (1)

def apply = { (2)val scn = scenario("My scenario")

.exec(http("My Page")

.get("http://mywebsite.com/page.html")) (3)List(scn.configure.users(10).ramp(10)) (4)

}}




Autres outils

Des outils propriétaires existent :HP Mercury LoadRunnerNeotys Neoload

Ils permettent de prendre en charge plus de protocoles, de simulerun véritable navigateur (Javascript) ou encore d’obtenir desrapports automatisés très simplement.



Pour comprendre

Table des matières

1 Performance ?

2 Méthodologie


4 Optimisation



Pour comprendre

MAT

Le Garbage Collector Java = libère de la mémoire un objetJava sans référenceUn vidage du tas (Heap Dump) Java est une image du graphed’objets Java complet à un instant T.

MAT permet d’ouvrir un Heap Dump et :de visualiser les références aux objetsd’affectuer des requêtes (SQL-like : OQL)de naviguer dans le graph

MAT Eclipse permet ainsi d’identifier les éventuelles fuites mémoire.



Table des matières

1 Performance ?

2 Méthodologie

3 Outils

4 Optimisation



Mauvaise utilisation de la base de données

Quelques exemples de mauvaises pratiques :Indexes manquants sur certains clefsRécupération de l’ensemble des colonnes pour effectuer uncalcul simpleMauvais choix d’isolation des transactions (locks)Pas de paramétrage de la base de données (pools)Rapprocher les traitements et les données (procéduresstockées et JOIN en SQL)

A retenirApprendre le fonctionne de sa base de données et observer lecomportement des requêtes (explain plan).



Utilisation abusive du réseau

Ne pas oublier que :Un accès réseau est plus de lent qu’un accès local(notamment en mémoire)Choisir correctement le protocole utiliséPréférer des appels "batchs" plutôt qu’un multitude d’appelsunitairesNe pas faire de sur-conception : un service pour une seuleapplication ?

A retenirEviter autant que possible les Round Trip réseau : pratiquer laméthode YAGNI



Mauvaise gestion de la concurrence d’accès

Quelques exemples de mauvaises pratiques :Des méthodes ou des blocks synchronized qui prennentbeaucoup de tempsDes transactions en base de données très longuesUtilisation abusive de structures de données synchronized(Hashtable, Vector, StringBuffer)

A retenirLes blocks synchronized sont l’ennemi de la performance.Envisager des approche par le pattern Actor.



Mauvaises performances du coeur technologique

Il arrive parfois qu’un composant soit :utilisé sans tenir compte des recommandations de ladocumentationutilisé pour autre chose que ce à quoi il était prévuré-écrit en pensant faire mieux

A retenirNe pas réinventer la roue, il y a de forte chance de faire moins bienque le voisin !



Consommation mémoire

Il y a trois types de problèmes avec la mémoire :beaucoup d’allocation d’objets à courte durée de vie (fortepression sur le GC)beaucoup d’objets persistants (OutOfMemoryError)des fuites mémoires (difficile à détecter)

A retenirUtiliser un profiler à différentes phases du cycle de vie del’application pour déteminer les points chauds.



Mauvaise utilisation des fonctions de cache

Un cache peut à la fois améliorer les performances et les dégrader.Mettre en cache des données changeantes ne présente aucunintérêtAvoir un ratio de succès trop bas sur le cache (données trèsdynamiques)Utiliser des locks pour implémenter son cache...

A retenirUtiliser un profiler à différentes phases du cycle de vie del’application pour déteminer les points chauds.



L’abus de XML

Le format XML n’est pas la panacée :Couteux en temps de parsing pour le CPUCouteux en stockage en mémoire

Il faut mettre en place certaines bonnes pratiques :Utiliser au maximum des API de streaming, StAX ou SAX,plutôt que DOMLors de transformation XSLT, essayer de compiler les feuillesde stylesEviter de relire plusieurs fois les mêmes documents !



Configuration du serveur d’application et JVM

Mettre en adéquation la configuration et la réalitée :Le pool de thread HTTP : nombre de threads autorisés surmon frontalLe pool de connexions SQL : nombre de connexion vers leSGBDLes paramètres de la JVM : mémoire, GC, traitement deserreursLes éléments spécifiques à votre application

A retenirTravail permanent de monitoring pour adapter la configuration àl’utilisation de l’application.



Logging excessif

Comme pour le cache, les logs peuvent être à la fois l’ami etl’ennemi :

Il est important d’obtenir des logs lors d’un test deperformancesL’activation des logs entraine une perte de performance :manipulation de String + écriture sur disque (sync)

A retenirUtiliser un framework qui permet d’utiliser des varargs plutôt quede la concaténation.


Annexe

Pour aller plus loin

Pour aller plus loin I

Charlie Hunt, Binu JohnJava Performance.Prentice Hall, 2011. ISBN 978-0137142521Joshua BlochEffective Java (2nd Edition).Addison-Wesley, 2008. ISBN 978-0321356680

Ian MolyneauxThe Art of Application Performance Testing.O’Reilly Media, 2009. ISBN 978-0-596-52066-3


Annexe


Pour aller plus loin II

WikipediaSoftware performance testinghttp://en.wikipedia.org/wiki/Software_performance_testing

http://decrypt.ysance.com/2012/09/tests-de-performances-partie-1-preparation-et-analyse/

Claude FalguiereMesurer les performances avec JMeter.http://fr.slideshare.net/claude.falguiere/mesurer-les-performances-avec-j-meter-cours-du-soir-valtech-25-mars-2010


http://en.wikipedia.org/wiki/Software_performance_testing

http://en.wikipedia.org/wiki/Software_performance_testing



http://fr.slideshare.net/claude.falguiere/mesurer-les-performances-avec-j-meter-cours-du-soir-valtech-25-mars-2010

http://fr.slideshare.net/claude.falguiere/mesurer-les-performances-avec-j-meter-cours-du-soir-valtech-25-mars-2010

Annexe


Merci

Merci de votre attention.Ces transparents sont sous licence CC-BY-SA-3.0http://creativecommons.org/licenses/by/3.0/fr/.


http://creativecommons.org/licenses/by/3.0/fr/

Tests de performances

Technology

Transcript of Tests de performances