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…