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)

1. 1
Tél : +33 (0)1 58 56 10 00
Fax : +33 (0)1 58 56 10 01
La performance en continu
50, avenue des Champs-Elysées
75008 Paris - FRANCE
© OCTO 2014 www.octo.com

2. 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. 3
> Pourquoi parler de
performance aujourd’hui ?

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.

5. 5
2 éléments de contexte

6. 6
Contexte #1: la génération Y

7. 7
Contexte #2: le mobile

8. 8
L’expérience
(douloureuse)
de MyMoney

9. 9 https://www.flickr.com/photos/timdorr/4092581313/

10. 10 https://www.flickr.com/photos/118887656@N06/14410310144/

11. 11
MyMoney !

12. 12
MyMoney !
@MyMoney Great App !

13. 13
Y’a un pb…
WTF ?

14. 14
Mais finalement…
MyMoney,
techniquement, c’est quoi ?

15. 15
Architecture
Serveur Front
Tomcat

16. 16
Etape #1: Regarder sous le capot

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

22. 22
Etape #2: Envoyer la charge

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

25. 25
Le recorder Gatling

26. 26
Scénario Gatling en scala

27. 27
Exemple de profil des tests de charge
0 Temps
10 000
750s

28. 28
Architecture
Serveur Front Supervision
Tomcat
Metrics
Injecteur

29. 29
$GATLING_HOME/conf/gatling.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
}
}
$GRAPHITE_HOME/conf/storage-schemas.conf
[Gatling stats]
priority = 110
pattern = ^gatling..*
retentions = 1s:6d,10s:60d

30. 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. 31
Gatling sur Grafana

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

36. 36
End User Monitoring

37. 37
End User Monitoring

38. 38
End User Monitoring

39. 39
End User Monitoring

40. 40
Démo !
End User Monitoring

41. 41
Etape #4: Automatiser

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

45. 45
Architecture
Serveur Front Supervision
Tomcat
Metrics
Injecteur
Agent AppD
IC

46. 46
Démo !
Automatisation

47. 47
Plugin Gatling pour Jenkins 1/3

48. 48
Plugin Gatling pour Jenkins 2/3

49. 49
Plugin Gatling pour Jenkins 3/3

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

54. 54
Si vous ne deviez emporter que 3
messages…

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

58. 58
Question ?
Questions ?

59. 59
Au passage…