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)
4. 4
Pourquoi parler de performances ?
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.
17. 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. 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. 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. 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. 21
Architecture
Serveur Front Supervision
Tomcat
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
23. 23
Pourquoi des tests de performance ?
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
24. 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
32. 32
Etape #3: Quand les problèmes ne sont pas dans le moteur
33. 33
Monitoring interne vs Monitoring externe
Portée du monitoring classique limité dans le data center
Environnement utilisateur Data center
Dans le data Center :
• Réseau interne
• Applications .NET, Java,
PHP
• Bases de données
• Autres serveurs internes
final
Utilisateurs éloignés :
• Depuis un navigateur
• Depuis le mobile
• Application desktop
• 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. 34
Définitions APM & EUM
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
35. 35
Monitoring externe : Architecture mise en place
Serveur Front Supervision
Tomcat
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
42. 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. 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. 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
50. 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. 51
Pour aller plus loin
Création d’environnements de tests de performance « à la volée »
Grâce à des outils de provisionning serveurs (ex: Chef ou Puppet)
name "java-app-server"
run_list("recipe[tomcat]")
override_attributes(
'tomcat' => {
'java_options' => "${JAVA_OPTS} -Xmx128M -Djava.awt.headless=true"
}
)
52. 52
Vers la performance en continu
HYPERVISEUR
AppServer
Chef
DbServer
Chef
1
JENKINS INJECTEUR
2
Tir de performance
Destruction environnement
1 Déploiement
1 Injection
3
Créer environnement
53. 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
55. 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. 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. 57
> Message #3
Si ça fait mal, il faut le faire souvent
èAutomatiser est la solution
Conclusion
BCH OCTO
Architecte depuis une 12aine d’année sur de gros projet java et web.
Je suis très intéressé par la Data: comment connecter les systèmes (API), ouvrir les systèmes (OpenData, OpenAPI) et créer de la valeur à partir des données (pour ça ce soir)
A OCTO, nous avons une équipe BDA de 12 personnes.
D’abord tech puis premier uses-case (analyse predictive, churn, déceller les patterns de consommation avec les données de CB, etc.)
La nouvelle génération née dans la ferveur technologique du 21ème siècle n'a pas connu les modems 56k contrairement à ses ainés.
Elle est habituée à l'instantané et est donc bien moins patiente !
On verra que c’est important à prendre en compte:
- Le contenu doit être adapté au device et à sa connexion… souvent la lenteur ne se situe pas côté serveur mais sur le réseau ou le browser
On va vous raconter l’histoire de la startup qui réalise l’App Money
C’est une histoire inventée mais c’est un pattern qu’on a souvent observé lors de nos différentes rencontres en tant que consultant
Une petite idée qui nait dans la tête de 3 entrepreneurs lors d’un startup WE
Les entrepreneurs, ce sont eux 3, devant, au premier plan…
Ils pensent un Business Model, se mettent à coder et assez rapidement sortent une appli mobile pour se confronter au marché…
Nos amis fonctionnent en Lean Startup
Si on revient à nos amis de Money…
Voici leur archi actuelle
Regarder sous le capot = On veut avoir une vision de ce qui se passe
Sur les serveurs
Dans l’application
Metrics permet d’afficher des métriques applicatives:
Hit ratio sur le cache
Nb de requêtes sur des EndPoints REST bien précis
Etc.
===========================
https://github.com/pkkummermo/grafana-vagrant-puppet-box
Graphite: http://localhost:9100/
Carbon: http://localhost:2003
statsd: http://localhost:9125:udp
ElasticSearch: http://localhost:9200
Grafana: http://localhost:9100/grafana
A l’intérieur de graphite, il y a Carbon pour le stockage
ES sert à sauver la conf Grafana
Le point 1 = détecter / anticiper les problèmes de Multi-threading (qui n’apparaissent que sous forte charge):
Deadlock
Pb d’Isolation BD
Contention (taille de pool, solicitation BDD, …)
C’est un outil pour les dévs
10 000 utilisateurs actifs
2s de think time
Répartition des profiles :
85% Utilisateur non loggué
5% Inscription d’un nouvel utilisateur
5% Un joueur à un jeu déconnecté pendant la partie
5% Un joueur à un jeu connecté pendant la partie
Scénario non loggué
750 secondes (12 minutes 30s)
donc à 10 000 utilisateurs actifs
un nouvel utilisateur toutes les 75ms
permet d’obtenir une répartition uniforme des types de requêtes du scénario
~ 5000 requêtes / s
12 500 utilisateurs simulés sur le test
permet d’obtenir un plateau
Parler du fait que les problèmes ne sont pas toujours dans le datacenter
Dans notre contexte (MyMoney), voici l’archi mise en place
Parler de ApDynamics comme APM
Montrer l’application MyMoney en cliquant sur le fameux bouton qui génère le problème de performance Javascript
Voir le diagnostique du problème sur la console APM
Faire le drilldown vers la partie serveur
Grâce au monitoring serveur et au End User, l’équipe Money a une visibilité 360° sur les performance et la qualité de service de l’appli
Grâce aux tirs de perfs, ils peuvent valider que leur appli tient la charge, sans erreur.
Ca aurait été mieux d’anticiper tout ça, non ?
Pourquoi ?
Ce schéma montre que, plus il y a de temps entre les actions, plus elles sont douloureuses.
Plus on espace les tests de charge, plus ils sont douloureux et compliqués à mettre en place
d’où le message suivant…
On rajoute donc Jenkins à notre archi pour piloter et automatiser les tests de perf
Parler de ApDynamics comme APM
Montrer l’application MyMoney en cliquant sur le fameux bouton qui génère le problème de performance Javascript
Voir le diagnostique du problème sur la console APM
Faire le drilldown vers la partie serveur
Il y a un plugin Gatling pour ça
Qui permet à Jenkins de piloter les tests et garder un historiquex
http://192.168.33.10:8080
On voit ici l’évolution des temps de réponse et du nb d’erreur dans le temps
Attention: le changement des scénarios oblige à recapturer les scripts
=> Coût à anticiper pour maintenir le code de tests
Nous accompagnons des clients pour automatiser entièrement leurs tests de performance.
Par exemple, Jenkins se charge toutes les nuits de
Provisionner une plateforme équivalente à la production
Popper de VM sur le Cloud Privé IaaS
Provisionner les middlewares (AS, BD, etc.) grâce à Puppet
Déployer la dernière version de l’application
Tirer la charge avec Gatling et récolter les métriques
Déprovisionner la plateforme à la fin des tests
Alerter en cas de dépassement des seuils
Grâce aux GdW (Silicon Valley) on a des outils puissants
=> Il ne faut pas s’en priver