Un petit tour des pratiques et outils de capacity planning. Graphite, JMX Trans, JMeter (sans frein à main), et leurs amis Amazon EC2, jenkins, VisualVM … Et en bonus la basic-web-perf application pour tester votre infrastructure à blanc !

1. Capacity Planning
Mesurer la capacité de votre
système

2. Plan
1/ Une capacité ?
2/ Se préparer
3/ Construire vos tests
4/ Conseils supplémentaires
5/ Notre expérience

3. 1/ Une capacité ?
Comprendre et définir le but à atteindre

4. Capacity Planning
• Le but :
• Mesurer la capacité de votre système
• Garantir un “domaine de vol”
• Les objectifs :
• ANTICIPER : éviter des problèmes évidents
• FOCALISER : ne pas travailler sur de faux problèmes
• CAPITALISER : pouvoir définir des seuils d’alerte
• EXPERTISE : maitrise du système en production
• Roder les relations Dev / Ops

5. Domaine de vol
• Le domaine de vol d'un avion est l'espace en
vitesse et altitude à l'intérieur duquel il peut
fonctionner en sécurité (vérifié)
• Pour un site :
• Altitude = Nombre d’utilisateurs
• Vitesse = pages vues/min

6. Traduire la capacité en chiffres
• Ce que le système doit fournir
• On part d’Indicateurs métier
• 2.000 ventes par jour
• Pic télé : 2000 visiteurs sur 10min
• Objectif annuel : 10 Millions de pages vues
• On traduit en indicateurs techniques
• 1.000.000 pages vues / j
• 10.000 pages vues / min en pic (5 min)

7. 2/ Se préparer
La préparation de l’environnement de test

8. Préparer 1/5 : Définir le lieu des tests
• Soit en production
• Idéal car preuve formelle de la capacité
• Attention à la pollution des données
• Soit sur un environnement dédié
• Duplication de la production (hard / soft)
• Mocking sur les interfaces non ciblées
• Ne validera pas forcément tout
• VRAIMENT dédié !

9. Préparer 2/5 : Définir des scénarios
• Il faut des scénarios précis :
• Définit un cadre
• Valide les objectifs sur le papier (calculs)
• Grands impacts lorsqu’on le change
• Se concentrer sur le chemin critique (pas exhaustif)
• Nécessaires pour :
• Planifier les quantités de données à injecter
• Définir l’infrastructure de test (partie utile)
• Idée Assez similaire aux Tests Unitaires

10. Préparer 3/5 : Avoir du monitoring
• Avoir un monitoring de prod
• Doubler avec un monitoring plus fin
• Graphite (ou autre base RRD)
• JMXTrans l’alié de Graphite
• Collecte des logs
• Syslog, logstash, splunk, ... mais faut le faire
• Ces parties peuvent être des bottlenecks de
votre production (logs, backups, ...)

11. Préparer 4/5 : Outillage d’injection
• Mise en place et vérification de l’infrastructure
• Capacité d’injection :
• Outillage et Scripts d’injection
• Capacité de mesure : vérifier les chiffres mesurés
• Double système de mesure ?
• Règlages
• Ne faire varier qu’un seul paramètre à la fois
• Vérifier les hypothèses et expliquer les différences
• Jouer et publier les tests
• Rejouer 3 fois les tests (surtout en cas de soucis)
• Publier pour assurer la tracabilité

12. Préparer 5/5 : Reporting
• Etre capable de collecter toutes les données
• Archivage systématique pour chaque tir
• Consultation / vérifications a posteriori
• Espace pour ajouter des notes
• Cas idéal : on photographie l’état instantané
de l'infra
• A complèter au fil des besoins

13. Assurez-vous un minimum !
• Vérifiez la capacité de votre infrastructure de test
• Capacité d’injection (injecteurs performants)
• Capacité de charge hors applicatif
• L’outil magique : basic perf webapp
• Une application blanche
• Temps de réponse
• Taille de la réponse
• Valide votre capacité à tester
• Ne pas y passer 100h !

14. Démo Basic Web Perf
En local

15. 3/ Construire vos tests
Choisissez vos outils

16. Outils d’injection
• A choisir avec soin !
•JMeter : good old friend
•LoadRunner : cher ami
•Gatling : La force brute
•TheGrinder : python
•Japex : micro benchmark
•Java : self made injector !
• Capacité de reproduire à grande échelle vos
scénarios et mesurer leur succès

17. JMeter
• Quelques bonnes recommandations JMeter
• Client HttpClient 4
• Stockage response en md5 (mémoire)
• JMeter plugins
• http://code.google.com/p/jmeter-plugins/
• UltimateThreadGroup
• Graphes ResponseCode / ResponseTime
• Console Status Logger
• Throughput Shaping Timer

18. Outillage d’automatisation
• Scripting
• Shell : l’éternel
• Ant/Maven
• Jenkins
• Scénarios, plugins
• Tracabilité, commentaires
• Amazon EC2
• Création de machines
• Démarrage/Arrêt

19. Monitoring
• Suivre le comportement de votre application
• Via JMX
• VisualVM, JMXTrans, ...
• Via les logs
• Outils de lecture des logs
• Conserver / Exporter vos mesures
• Graphite (base RRD)
• Zabbix / Munin
• Java Melody

20. 4/ Notre expérience
Le cas de LesFurets.com

21. Le cas LesFurets.com
• Test sur la production avec 2 scénarios
• Scénario 1: Capacité du chemin critique
• Scénario 2: Pic télé
• Scénario 3: Assureurs unitairement
• Environnement LT et Production
• LT : Duplication de la prod
• Production : sans appels aux assureurs (mode
« benchmark »)

22. Le cas LesFurets.com
Travail sur les scripts :
• Fixer l’objectif et les metriques à utiliser
• Variabilisation des caches GWT
• Enregistrer les Selenium IDE, puis Java
• Variabiliser les scripts (pilotage, éviter le cache,
fiabiliser les data) → % de parcours
• Fiabiliser le script (ultimate thread group,
throughputs, scenarii variables, retour MD5)
• Anonymiser toutes les datas de test
• Création d'un « cahier de tests »

23. Le cas LesFurets.com
Clonage des environnements de PROD :
• Monter des machines semblables à celles de
prod (1/2 prod en capacité)
• Mocker les communications extérieures
• Mode « benchmark » déjà en place
• Besoin d'un script de nettoyage BDD pour la
prod
• Compléter la collection de sondes JMX
« métier »

24. Le cas LesFurets.com
Monitoring et reporting :
• Mise en place de Graphite / JMXTrans en LT et
en PROD
• Double monitoring Graphite / Zabbix
• Tests des injecteurs avec VisuelVM
• Stockage des données de monitoring pour
lecture ultérieure, sous référence du tir
• Reporting tir par tir, sur CONFLUENCE

25. Automatisation du procédé
• Automatisation du tir et collecte de résultats
• Construction de scripts shell
• Intégration jenkins des scripts
• Externalisation injection sur EC2
• AMI pour les injecteurs
• Plugin Jenkins EC2 et build flow
• Reporting
• Edition d'un rapport regroupant graphite,
Jmeter, lofs et JTL …
• Historisation et classement sur CONFLUENCE

26. Conséquences
• Mise en place CDN
• Travail sur la bande passante entre serveurs
• Fix de certains algorithmes synchrones
• Nouveaux réglages de JVM
• Suppression de verrous « système » (connec
TCP, I/O wait liées aux batches)
• Pistes non exploitées :
• Logs sur application consacrée
• Création de Sprites
• Optimisation GWT
• Utilisation du procédé à chaque recette

27. Des conseils supplémentaires
Attention aux pièges

28. A mesurer
• Les informations indispensables
• Requetes : Temps de réponse / Code de retour
• Mémoire : Max / Free : serveurs ET injecteurs
• CPU : serveurs ET injecteurs
• Réseau : I/O Disque, bande passante, ...
• SQL : Nb requetes, rq lentes SQL, ...
• Valeurs métier injectées ET cibles
• Utilisateurs / pages vues
• La capacité que vous cherchez
• Activité Garbage Collector

29. Enregistrement des tests
•Enregistrez la réalité
•Un script HUMAIN et MANUEL
•Puis anonymisation / suppression du superflu
•Puis variabilisation
•Puis paramétrage / installer le pilote
•A refaire à chaque version !
•Idée : Selenium puis JMeter
•Garantir que le test est réaliste + stabilité pour
chaque ré-enregristrement

30. Configuration Java
• Activez les traces log
• Activez le DumpOnOOME
• Versions de java et memoire attribué JVM a
calquer sur PROD si on utilise un clone
• Intégrez des mesures JMX
• Configuration de l’accès via VisualVM
• Produisez des Logs utiles !
• N’oubliez pas de les regarder

31. Menagez votre banc de test !
• S'assurer de la scalabilité de l'infra : pouvoir
tirer à dimension réduite !
• Scalabilité par serveur et par machine
• Monter en puissance doit être progressive

32. Attention aux fuites !
• Vérifiez
• Envois de Mails
• Anonymisation des données
• Connexion à des systèmes tiers
• Logs et accès aux bases de données
• Toujours prévenir l'équipe qu'une campagne de
tests est menée : les activités du groupe
peuvent influer sur l'environnement du test !

33. Ne laissez aucune trace !
• Vérifiez
• Données de test supprimées de la PROD
• Logs de test ôtés de la PROD
• Les métriques (trafic réseau, activité CPU, load
average, …) sont revenues à la normale