"la performance en continue" à jmaghreb 3.0 - 05/11/2014
DESCRIPTION
Au cours de cette session, nous plongerons avec vous dans le quotidien d’une startup qui vient de se lancer sur le Net. Alors que les premiers utilisateurs affluent vers ses serveurs, l’équipe se retrouve confrontée à ses premiers problèmes de performance. Le prix du succès… ! Nous verrons avec eux comment simuler une arrivée massive d’utilisateurs pour “stresser” leur plateforme. Nous utiliserons les outils d’APM pour monitorer les serveurs et applications Java mais aussi évaluer l’expérience utilisateur. Enfin, nous proposerons une démarche et des outils pour tester la performance en continue. Avec de nombreuses démos en live, cette session en français s’adresse aux développeurs, architectes et décideurs sur les projets IT. Animé avec Landry DEFO KUATE (OCTO)TRANSCRIPT
1
Tél : +33 (0)1 58 56 10 00 Fax : +33 (0)1 58 56 10 01 www.octo.com © OCTO 2014
50, avenue des Champs-Elysées 75008 Paris - FRANCE
La performance en continu
2
Qui sommes nous ?
Benoît de CHATEAUVIEUX
Senior Architect @OCTO Organisateur « Casa Big Data Meetup »
@benchato
Landry DEFO KUATE
Architecte @OCTO
Organisateur « Perf-UG Maroc » @defolandry
3
> Pourquoi parler de performance aujourd’hui ?
4
La lenteur d'une application était ressentie au bout de 4 secondes en 2008, elle l'est au bout de 3 secondes en 2014.
Google à 500ms slowdown == 20% decrease in ad revenue. Microsoft Bing à a 2-second slowdown == 2.5% decrease in queries and overall clicks. Amazon à 100ms slowdown - one tenth of a second! - == a 1% decrease in revenue. Yahoo! à a 400ms improvement in load time == 9% increase in traffic. Mozilla à 2.2s improvement == 60 million additional Firefox downloads.
Pourquoi parler de performances ?
5
2 éléments de contexte
6
Contexte #1: la génération Y
7
Contexte #2: le mobile
8
L’expérience (douloureuse)
de MyMoney
9https://www.flickr.com/photos/timdorr/4092581313/
10https://www.flickr.com/photos/118887656@N06/14410310144/
11
MyMoney !
12
MyMoney !
@MyMoney Great App !
13
Y’a un pb… WTF ?
14
Mais finalement… MyMoney,
techniquement, c’est quoi ?
15
Architecture
Tomcat
Serveur Front
16
Etape #1: Regarder sous le capot
17
Démarche de mise en place de la supervision
>Instrumenter l’application avec le Framework Metrics et exposer les métriques recueillies e JMX
>Extraire périodiquement les métriques depuis JMX et les envoyer vers le serveur de monitoring
>Stocker les informations de performance, computing de statistiques aggrégées
>Tableaux de bord de supervision
18
JMXTrans Le connecteur manquant :
Métriques de la JVM via JMX ó logging / monitoring / graphing 2 modes
PULL: installé au niveau de Graphite, il va interroger la JVM PUSH: déployé comme agent Java, il instrumente la JVM et pousse
les métriques vers Graphite Projet Open source
Metrics Librairie Java qui permet de remonter, via JMX, des métriques
depuis le code de production Propose
Gauges (une valeur ponctuelle dans le temps) Compteurs (nombre d’appels à la méthode) Histogrammes (distribution de valeurs sur un stream de données) Mesures (taux d’occurrence d’un événement)
Timer (durée d’un type de traitement) Health Check (Ping global -> OK/NOK)
Projet Open Source
1 - Remonter les métriques: Metrics & JMXtrans
19
Graphite fait 2 choses 1. Stocke des données numériques sous forme de time-series 2. Génère des graphs de ces données à la demande
Graphite ne collecte pas la donnée. C’est le boulot de JMXTrans et Metrics
Graphite se compose de 3 briques:
2 – Collecter avec la stack Graphite
Carbon deamon
Graphite webapp
Whisper
Démon qui reçoit les données timeseries
Webapp Django qui génère des
graphiques
BD qui stocke les time-series
20
3 – Restituer avec Grafana
Affiche des tableaux de bord à partir de métriques Graphite Histogrammes, courbes, points Recherche et opérations possible sur des métriques Graphite Modèles de tableau de bord réutilisables Similaire à Kibana
21
Architecture
Tomcat
Serveur Front Supervision
Metrics
Mise-à-jour du code sur la base du Framework Metrics Installation de l’agent de collecte JmxTrans Ajout d’un serveur de supervision pour le stockage et la consultation des métriques
22
Etape #2: Envoyer la charge
23
Assurer qu’un système fonctionne sans erreurs sous certaines conditions de
charge
Optimiser les temps de réponse èaugmenter la satisfaction utilisateur
(performance as a feature)
Optimiser les coûts infrastructure et du run
Pourquoi des tests de performance ?
24
Gatling
Gatling est un framework de tests de charge Open Source basé sur Scala, Akka et Netty
Haute performance HTTP Concepts simples Recorder de Scenario DSL pour écrire les scénarios Rapports
25
Le recorder Gatling
26
Scénario Gatling en scala
27
Exemple de profil des tests de charge
Temps 0
10 000
750s
28
Architecture
Tomcat
Serveur Front Supervision
Metrics
Injecteur
29
$GATLING_HOME/conf/gatling.conf
$GRAPHITE_HOME/conf/storage-schemas.conf
Realtime Monitoring de Gatling
data { writers = "console, file, graphite" reader = file
graphite { host = "192.168.56.101" port = 2003 #light = false # only send the all* stats #protocol = "tcp" # Choose between 'tcp' or 'udp' #rootPathPrefix = "gatling" #bucketWidth = 100 #bufferSize = 8192 }}
[Gatling stats]priority = 110pattern = ^gatling\..*retentions = 1s:6d,10s:60d
30
2 possibilités pour exécuter des tirs de charge avec Gatling Via le shell Gatling
En utilisant Maven
Exécuter les scripts
31
Gatling sur Grafana
32
Etape #3: Quand les problèmes ne sont pas dans le moteur
33
Monitoring interne vs Monitoring externe Portée du monitoring classique limité dans le data center
Dans le data Center : • Réseau interne • Applications .NET, Java,
PHP • Bases de données • Autres serveurs internes
Utilisateurs éloignés : • Depuis un navigateur • Depuis le mobile • Application desktop
Data center Environnement utilisateur final
• Problème de téléchargement des ressources applicatives (Exemple QoS du FAI)
• Problèmes d’éxécution de la partie client des applications riches reposant sur HTML5 et Javascript (Exemple : stack AngularJs, GWT)
• Erreurs d’éxécution de l’application sur le poste utilisateur (Erreurs Javascript)
• Indisponibilité de l’application à cause d’un problème d’accès au réseau interne (Erreurs HTTP 404)
• Visibilité complète dans tout le datacenter
34
APM (Application Performance Management) Permet de contrôler la performance des applications métiers et de mettre en avant rapidement d'éventuels problèmes, directement liés aux logiciels, voire même à leur environnement (réseau, système, base de données...)
EUM (End User Monitoring) Permet de mesurer la performance d’une application à partir de l’environnement de travail de l’utilisateur final (navigateur, poste de travail, mobile) et non pas à l’entrée du Datacenter seulement
Définitions APM & EUM
35
Monitoring externe : Architecture mise en place
Tomcat
Serveur Front Supervision
Metrics
Injecteur
Agent AppD
Installation de la stack AppDynamics dans le serveur de supervision Dépliement de l’agent AppDynamics sur les serveurs d’application Ajout du script de supervision Web dans l’application AppDynamics transmet les métriques de supervision Web par Internet
36
End User Monitoring
37
End User Monitoring
38
End User Monitoring
39
End User Monitoring
40
Démo !
End User Monitoring
41
Etape #4: Automatiser
42
> Constat
Généralement, des tests de charge sont réalisés juste avant de passer en production.
C’est bien…mais c’est trop tard !
è L’industrialisation des tests permet de les exécuter
dès le début du projet, en continu
43
La fréquence réduit la difficulté
If it hurts, do it more often. Si c’est douloureux, il faut le faire souvent
44
Jenkins permet de planifier et monitorer des tâches automatiques.
Il est sert de base aux Usines de Développement et permet l’intégration continue.
Il est extrêmement extensible grâce à un grand nombre de plugins.
Jenkins
45
Architecture
Tomcat
Serveur Front Supervision
Metrics
Injecteur
Agent AppD
IC
46
Démo !
Automatisation
47
Plugin Gatling pour Jenkins 1/3
48
Plugin Gatling pour Jenkins 2/3
49
Plugin Gatling pour Jenkins 3/3
50
Pourquoi intégrer les tests de charge Gatling dans Jenkins ? Pour les piloter facilement Pour versionner les scénarios Pour archiver les rapports Pour tracer les résultats
Attention, à l’automatisation ! Si les tests ne sont pas tirés sur la plateforme cible (prod, pré-prod)
Ils ne permettent pas de valider la tenu en charge de l’application en cible Dimensionnement des serveurs différents
Stack techno différente (Tomcat en dev, Websphere en Prod) Volume et qualité de données « de test » souvent non représentatifs
En revanche, ils permettent de détecter au plus tôt des régressions Temps de réponse
Locks (threads, BD, etc.) …
Opportunité
51
Création d’environnements de tests de performance « à la volée » Grâce à des outils de provisionning serveurs (ex: Chef ou Puppet)
Pour aller plus loin
name "java-app-server"run_list("recipe[tomcat]") override_attributes( 'tomcat' => { 'java_options' => "${JAVA_OPTS} -Xmx128M -Djava.awt.headless=true" } )
52
Vers la performance en continu
HYPERVISEUR
AppServer Chef
DbServer Chef
1
2
Tir de performance
Destruction environnement
1 Déploiement
1 Injection
3
JENKINS INJECTEUR
Créer environnement
53
Détection rapide de la cause principale des problèmes sur la plateforme
Passée de quelques jours à quelques minutes
Reproduction en pré-production de la charge supportée par la plateforme pendant les périodes de peak
Détection automatiquement en pré-production d’éventuels problèmes de performance causés par des modifications effectués dans l’application
Anticipation des problèmes de performance avant même que le client ne s’en rende compte
Maîtrise du comportement de l’application sur les environnements client
navigateur, mobile
Gains obtenus
54
Si vous ne deviez emporter que 3 messages…
55
> Message #1
Les tests de perf DOIVENT être intégrés tout au long du cycle de développement de l’application
(et pas comme une validation 1 semaine avant la MEP)
Conclusion
56
> Message #2
De puissants outils Open-Source de monitoring et d’injection de charge existent
Les suites d’Application Performance Management et de End User Monitoring actuelles sont
payantes (pas de solutions Open-Source crédible). Elles existent en SaaS et on-Premises et sont très matures
Conclusion
57
> Message #3
Si ça fait mal, il faut le faire souvent èAutomatiser est la solution
Conclusion
58
Question ?
Questions ?
59
Au passage…