Le document présente un atelier sur les tests de performance, mettant en avant l'importance de mesurer les temps de réponse et la charge d'un système applicatif. Il aborde différentes méthodologies de tests, y compris les tests de performance, tests de charge, et tests de rupture, ainsi que des outils pour optimiser ces performances comme Gatling. L'atelier inclut également des exemples pratiques et des discussions sur les défis et les meilleures pratiques en matière de performance.

1. Performance User Group #1
Marc BOJOLY, OCTO Technology
Henri TREMBLAY, OCTO Technology

2. • Wifi
• Récupérer le lab
git clone https://github.com/perfug/sampleapp1.git
• Compiler et tester l’exécution
– Voir README.MD
• L’importer dans votre IDE préféré
• Récupérer GCViewer (optionnel)
2
Avant de commencer

3. • Introduction (5 min.)
– Le Performance User Group Paris
• Présentation (30 min.)
– Performance for the dummies : introduction aux tests de charge
• Hands-on-lab (55 min.)
– Une application modélisant un front-office
– Un injecteur : gatling
– De quoi s’amuser !
• Questions / réponses (15 min.)
3
CONTENU DE LA SOIREE

4. Wikipedia
« [Les tests de performance] vont avoir pour objectif
de mesurer les temps de réponse d'un
système applicatif en fonction de sa
sollicitation. Cette définition est donc très
proche de celle de test de charge où l'on
mesure le comportement d'un système en
fonction de la charge d'utilisateurs simultanés.
Seuls les tests de charge permettent de valider
correctement une application ou un système
avant déploiement, tant en Qualité de Service
qu'en consommation de ressources. »
4
BIENVENUE AU PERFORMANCE USER GROUP
Larousse
Résultat chiffré (en temps
ou en distance) d'un
athlète ou d'un cheval à
l'issue d'une épreuve.
La performance d’un
système informatique
est caractérisée par les
temps de traitement
dans un contexte et
sous une sollicitation
donnés.

5. 5
NOTRE VISION ?
Source : www.arthursclipart.org
Les performances
d’un système sont une
spécification
fonctionnelle implicite
du système

6. 6
NOTRE VISION ?
Source : Les géants du Web
La mesure de
performance doit être
au cœur du processus
de développement
informatique

7. 7
Notre vision ?
Source : Les géants du Web
Nous voulons des
systèmes performants

8. 8
NOTRE DEVISE ?
LES TEMPS DE RÉPONSE NOUS DIMINUERONS
LES DÉBITS NOUS AUGMENTERONS
LES RESSOURCES NOUS ÉPARGNERONS
LA HAUTE DISPONIBILITÉ NOUS
PRÉCONISERONS

9. 9
NOTRE MISSION?
Source : Paris JUG
Offrir un lieu
d’échanges informels
où toutes les
personnes intéressées
par l’optimisation et la
performance sont les
bienvenues quel que
soit leur niveau

10. 10
NOTRE MISSION ?
Faciliter la diffusion
des derniers outils et
des meilleures
techniques pour
maîtriser au plus tôt la
performance d’un
système informatique

11. PerfUG - Performance for the
dummies
Introduction aux tests de charge
11

12. Un exemple de démarche
12
Et ensuite?
Les tests de performance
Les tests de charge
SOMMAIRE

13. 13
Et ensuite?
Les tests de performance
Les tests de charge
Un exemple de démarche
SOMMAIRE

14. 14
LES DIFFÉRENTS TYPES DE TEST
• Objectif : mesurer la performance unitaire
• Ex : le use case de souscription est testé pour 1 utilisateur
et, pour chaque étape du use case, on mesure le temps
passé dans les différents composants de l’application
Test de
performance
• Objectif : mesurer la tenue en charge de l’application sur la
population cible
• Ex : on simule l’utilisation de l’application par 200 utilisateurs
en parallèle pendant 2h
Test de
charge
• Objectif : déterminer les limites de l’application
• Ex : on augmente le nombre d’utilisateurs en parallèle sur
l’application jusqu’à ce que le taux d’erreurs / les temps de
réponse ne soient plus acceptables
Test de
rupture
• Objectif : déterminer la capacité de l’application à fonctionner
sur une période étendue
• Ex : on simule l’utilisation de l’application pendant 48h, avec
une charge constante et égale à la charge moyenne
Test de
vieillissement

15. Démarche de test que nous utilisons
Mise en place
des mesures
et scénarios
Exécution des
scénarios
Optimisation
Estimation des
gains potentiels
• Vérifier les
environnements
• Définition des scénarios
représentatifs pour
l’étape de tests de
charge
• Génération des jeux de
données
• Définition d’une cible à
atteindre
• Tests de charge avec
une volumétrie
représentative de la
production
• Exécution de tests de
performance locaux sur
les « hot spot » et
tuning en fonction du
résultat
• Validation des
hypothèses
Tests de charge Tests de performance
15

16. 16
Et ensuite?
Les tests de performance
Les tests de charge
Un exemple de démarche
SOMMAIRE

17. Méthodologie d’un test de charge
Définition du plan et des
cas de test
Plan de test Cas de test
2 Création des scénarii et
des scripts de tests
3 Enregistrement des
métriques
4
Consolidation des
métriques et édition
d’un rapport de test
5
Analyse du rapport de
test et émission des
préconisations Rapport d’analyse
Métriques
Rapport de test
Contrôleur
Scripts de test Scénarii de test
Capture des
métriques
Application cible
Injecteurs
Données de test
1 Création des paliers de
données
Exécution : simulation
d’utilisateurs
1
3
3
17

18. GÉNÉRER LES DONNÉES
Identifier les ressources en quantité limitante
Identifier les impacts sur les différentes
machines lorsque l’application est distribuée
Corréler l’évolution des temps de réponse et les
consommations de ressources sur les
différentes machines
MONITORER LA CONSOMMATION DE
RESSOURCES
Enregistrer et rejouer de manière fidèle un
ensemble d’actions utilisateurs.
Variabiliser ces actions utilisateurs pour être
représentatif de l’usage réel
Simuler un grand nombre d’utilisateurs
TESTER EN CHARGE
Migrer les données depuis la production mais il faut
souvent l’anonymiser.
Générer un jeux de données mais il doit être
représentatif
Rétablir le jeux de données dans son état initial une
fois le tir effectué
18
Windows
LES OUTILS À UTILISER
NMon
Un outil fantastique
dont vous souhaiteriez
partager?

19. LES GRANDS TYPES DE GOULETS D’ÉTRANGLEMENT
INSTABILITÉ DU SYSTÈME = ECHEC DU TEST !
Toute exception doit être analysée
Les causes peuvent être multiples et liées à la charge (fuite
mémoire, fuite de connection, fuite de threads…)
Ou pas 
INFO: Server startup in 7722 ms
Apr 7, 2013 7:57:38 PM org.apache.tomcat.util.net.NioEndpoint processSocket SEVERE: Error
allocating socket processor
java.util.concurrent.RejectedExecut
ionException
at
java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.jav
a:1956)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:816)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1337)
at org.apache.tomcat.util.net.NioEndpoint.processSocket(NioEndpoint.java:1272)
at org.apache.tomcat.util.net.NioEndpoint.processSocket(NioEndpoint.java:1259)
at org.apache.tomcat.util.net.NioEndpoint.processSocket(NioEndpoint.java:1251)
at org.apache.tomcat.util.net.NioEndpoint$Poller.processKey(NioEndpoint.java:1689)
at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1627)
at java.lang.Thread.run(Thread.java:679)
SATURATION DES RESSOURCES
La saturation d’une ressource est un début ou un aboutissement
Goulet d’étrangement à adresser pour passer à l’échelle
Ou point de départ de l’optimisation
CPU
19
I/O
LOCKS ET DEAD LOCKS
L’absence de toute autre cause est souvent ce qui met sur la voie
d’un problème de lock.
L’analyse des deadlocks peut en soit nous occuper toute une
séance….
CPU
I/O

20. 20
Les nouveautés
Les tests de performance
Les tests de charge
Un exemple de démarche
SOMMAIRE

21. LES TESTS DE PERFORMANCE
21
OBJECTIFS
Affiner l’analyse et la compréhension des problèmes de performance.
Tester différentes alternatives d’optimisation possible et mesurer les améliorations qu’elles
apportent.
Itérer facilement entre différentes optimisations possibles.
MÉTHODOLOGIE
L’objectif ici n’étant pas d’obtenir des mesures exactes, des instrumentations plus intrusives sont
envisageables
Les investigations sont réalisées
• Avec les sources du code
• Sur un poste de développement ou avec une manière de déployer très fréquemment
• Avec les droits d’administration pour réaliser tout cela….

22. L’optimisation de performances se fait en intervenant sur plusieurs niveaux
Principes d’optimisation
22
• Ex : optimisation algorithmique, gestion du
multi-threading
Code et
architecture
applicative
• Ex : tuning des paramètresFramework
• Ex : taille des pools de
threads, taille de la mémoire
allouée à la base…
Couches basses : base
de données, serveur
d’application
• Ex : nb
machines, configurat
ion réseau…
Infrastructure
L’OPTIMISATION

23. La mesure est un point essentiel dans l’optimisation des performances.
POINTS DE VIGILANCE
L’infrastructure doit être proche de l’infrastructure cible pour que les
tests soient pertinents.
23
Les temps de réponse des systèmes externes sollicités doivent aussi
être consciencieusement mesurés.
Les jeux de données utilisés doivent être représentatifs des données
de production pour que les résultats soient pertinents

24. Hands-on Lab
24

25. • Une application « POC »
– 5 actions possibles / 9 tables
– API exposée sous forme d’URL GET
pour faciliter la testabilité
– Prépackagé avec H2
• Une application Front Office
– Encaissement d’article
– Calcul d’un total avec TVA variable par
pays et par catégorie d’article
– Gestion d’un stock par magasin
• Une architecture classique
– Hibernate / Spring / Spring MVC
– Stateless
Newsql App
25

26. • README
cd front
run.bat
<MyBrowser> http://localhost:8080/
cd injector
run.bat
• 1er tir avec Gatling
– Environ 60 s. de tir
– 31 req/s. sur mon portable
• Objectifs
– Quel débit maximum vous
pouvez atteindre avec votre
machine ?
– Quel est le goulet
d’étranglement?
HANDS-ON LAB HOW-TO ?
1 POM avec services, models et
data repositories
1 POM Spring
MVC
Injecteur Gatling
Ouvrir
Injector/target/gatling/
newsqlsimulation-YYYYMMDDHHmmss/index.html
26

27. Le scénario se trouve dans
injector/src/test/scala/NewSqlSimulation.scala
CONFIGURATION DE GATLING
27

28. • 1 utilisateur effectuant 1 scénario en boucle
• 1 tir de chauffe
– Permet de charger les caches
– Permet de stabiliser la JVM
• 1 tir réel
– Permet de mesurer les temps de réponse
unitaire
– Nécessite d’avoir une cible de temps de
réponse
Étape 1: Test de performance

29. • users = 1/0/0
• rampUp = 0
• duration = 30
• 1 scénario à la fois (séquentiellement?)
• checkStatus + regexp
Étape 1: Configuration Gatling

30. • Suivi GC
-XX:+PrintGCDetails -XX:+PrintTenuringDistribution -Xloggc:gc.log
• Suivi compilation
-XX:-PrintCompilation
Étape 1: Configuration JVM

31. • Nombre d’utilisateurs cible effectuant les
scénarii en boucle
• 1 tir de chauffe
– Permet de charger les caches
– Permet de stabiliser la JVM
• 1 tir réel
– Permet de mesurer les temps de réponse en
charge normale
– Permet de les comparer aux temps de réponse
unitaire pour établir la dégradation
Étape 2: Test de charge

32. • users = 80/10/10
• rampUp = 10
• duration = 40
• Tous les scénarii simultanément
Étape 2: Configuration Gatling

33. • Moyenne
– Donne une idée des performances
– Haute: Pas bon
– Basse: Peut-être bon
Étape 2: Les métriques
0
1000
2000
3000
4000
5000
6000
7000
0,5s 1s 1,5s 2s
Nombre de requêtes
Nombre de
requêtes

34. • Écart-type
– Donne une idée de la stabilité du système
– Haut: Pas bon
– Basse: Peut-être bon
– Mais en pratique, doit être utilisé avec le
centile
Étape 2: Les métriques

35. • Centile 95 et 99 (ou autres)
– Très utile pour connaître les ralentissements
qu’auront un certain pourcentage de vos
utilisateurs
– Avoir une cible pour savoir ce que l’on est prêt
à accepter ou non
Étape 2: Les métriques

36. • Ajout constant d’utilisateurs effectuant les
scénarii en boucle
• On arrête dès que l’on reçoit des erreurs
ou que les temps de réponse deviennent
particulièrement long
Étape 3: Test de rupture

37. • users = 640/80/80
• rampUp = 160
• duration = 860
• Tous les scénarii simultanément
• Ctrl+C et générer le rapport
– ro.bat
Étape 3: Configuration Gatling

38. • Nombre d’utilisateurs cible effectuant les
scénarii en boucle
• Think times minimaux
• On surveille
– Une potentielle dégradation des
performances
– Une augmentation de la mémoire (« memory
leak »)
Étape 4: Test d’endurance

39. • users = 160/20/20
• rampUp = 10
• duration = 2000
• think ratio = 0
• Tous les scénarii simultanément
Étape 4: Configuration Gatling

40. Sommaire
Les tests de performance
Les tests de charge
Un exemple de démarche
Et ensuite?

41. QUELQUES PISTES POUR LES PROCHAINES SÉANCES
41
L’ÉVOLUTION DES ARCHITECTURES PHYSIQUES
Optimisation de la parallélisation pour bénéficier des architectures multi-core
Monitoring des environnements virtuels et assurer des quotas de ressources
Optimisation du scheduling de tâches dans un environnement multi-tenant (processeur Unix
ou Jobs Hadoop)
…
L’ÉVOLUTION DES OS ET DES MIDDLEWARES
Non-blocking I/O, Node.JS : concurrence au niveau des I/O
GC et ses limites
…
L’ÉVOLUTION DES DES MÉTHODOLOGIES
Les meilleures solutions de monitoring (AppDynamics, Dynatrace…)
Les fonctionnalités des différents profiler (JVisualVM, Yourkit, DotTrace…)
Les possibilités de tuning des bases de données (Insider de FourthElephant)
L’inclusion au sein de l’usine de build (gatling-maven-plugin, …)
…

42. Qu’est-ce qui vous donnerait envie de participer à ce
User Group ?
ET VOUS ?
42