Capacity PlanningMesurer la capacité de votre système

Plan

1/ Une capacité ?2/ Se préparer3/ Construire vos tests4/ Conseils supplémentaires5/ Notre expérience

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

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

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

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)

2/ Se préparerLa préparation de l’environnement de test

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é !

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

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

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é

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

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 !

Démo Basic Web PerfEn local

3/ Construire vos testsChoisissez vos outils

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

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

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

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

4/ Notre expérienceLe cas de LesFurets.com

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 »)

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 »

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 »

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

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

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

Des conseils supplémentairesAttention aux pièges

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

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

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

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

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 !

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