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...
2 
Qui sommes nous ? 
Benoît 
de CHATEAUVIEUX 
Senior Architect @OCTO 
Organisateur 
« Casa Big Data Meetup » 
@benchato 
...
3 
> Pourquoi parler de 
performance aujourd’hui ?
4 
Pourquoi parler de performances ? 
La lenteur d'une application était ressentie au 
bout de 4 secondes en 2008, elle l'...
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
9 https://www.flickr.com/photos/timdorr/4092581313/
10 https://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 
Serveur Front 
Tomcat
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é...
18 
JMXTrans 
Le connecteur manquant : 
Métriques de la JVM via JMX ó logging / monitoring / graphing 
2 modes 
PULL: ins...
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ée...
20 
3 – Restituer avec Grafana 
Affiche des tableaux de bord à partir de métriques 
Graphite 
Histogrammes, courbes, point...
21 
Architecture 
Serveur Front Supervision 
Tomcat 
Metrics 
Mise-à-jour du code sur la 
base du Framework Metrics 
Insta...
22 
Etape #2: Envoyer la charge
23 
Pourquoi des tests de performance ? 
Assurer qu’un système fonctionne sans 
erreurs sous certaines conditions de 
char...
24 
Gatling 
Gatling est un framework de tests 
de charge Open Source basé sur 
Scala, Akka et Netty 
Haute performance 
H...
25 
Le recorder Gatling
26 
Scénario Gatling en scala
27 
Exemple de profil des tests de charge 
0 Temps 
10 000 
750s
28 
Architecture 
Serveur Front Supervision 
Tomcat 
Metrics 
Injecteur
29 
$GATLING_HOME/conf/gatling.conf 
Realtime Monitoring de Gatling 
data { 
writers = "console, file, graphite" 
reader =...
30 
2 possibilités pour exécuter des tirs de charge avec Gatling 
Via le shell Gatling 
En utilisant Maven 
Exécuter les s...
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 
Environnement uti...
34 
Définitions APM & EUM 
APM (Application Performance Management) 
Permet de contrôler la performance des applications 
...
35 
Monitoring externe : Architecture mise en place 
Serveur Front Supervision 
Tomcat 
Metrics 
Injecteur 
Agent AppD 
In...
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’es...
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 ...
45 
Architecture 
Serveur Front Supervision 
Tomcat 
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énari...
51 
Pour aller plus loin 
Création d’environnements de tests de performance « à la volée » 
Grâce à des outils de provisio...
52 
Vers la performance en continu 
HYPERVISEUR 
AppServer 
Chef 
DbServer 
Chef 
1 
JENKINS INJECTEUR 
2 
Tir de performa...
53 
Détection rapide de la cause principale des problèmes sur la 
plateforme 
Passée de quelques jours à quelques minutes ...
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 pa...
56 
> Message #2 
De puissants outils Open-Source 
de monitoring et d’injection de charge existent 
Les suites d’Applicati...
57 
> Message #3 
Si ça fait mal, il faut le faire souvent 
èAutomatiser est la solution 
Conclusion
58 
Question ? 
Questions ?
59 
Au passage…
Prochain SlideShare
Chargement dans…5
×

"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014

888 vues

Publié le

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)

Publié dans : Ingénierie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
888
Sur SlideShare
0
Issues des intégrations
0
Intégrations
22
Actions
Partages
0
Téléchargements
51
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 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
  • "La Performance en Continue" à JMaghreb 3.0 - 05/11/2014

    1. 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. 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. 3 > Pourquoi parler de performance aujourd’hui ?
    4. 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. 5 2 éléments de contexte
    6. 6. 6 Contexte #1: la génération Y
    7. 7. 7 Contexte #2: le mobile
    8. 8. 8 L’expérience (douloureuse) de MyMoney
    9. 9. 9 https://www.flickr.com/photos/timdorr/4092581313/
    10. 10. 10 https://www.flickr.com/photos/118887656@N06/14410310144/
    11. 11. 11 MyMoney !
    12. 12. 12 MyMoney ! @MyMoney Great App !
    13. 13. 13 Y’a un pb… WTF ?
    14. 14. 14 Mais finalement… MyMoney, techniquement, c’est quoi ?
    15. 15. 15 Architecture Serveur Front Tomcat
    16. 16. 16 Etape #1: Regarder sous le capot
    17. 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. 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. 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. 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. 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. 22 Etape #2: Envoyer la charge
    23. 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. 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. 25 Le recorder Gatling
    26. 26. 26 Scénario Gatling en scala
    27. 27. 27 Exemple de profil des tests de charge 0 Temps 10 000 750s
    28. 28. 28 Architecture Serveur Front Supervision Tomcat Metrics Injecteur
    29. 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. 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. 31 Gatling sur Grafana
    32. 32. 32 Etape #3: Quand les problèmes ne sont pas dans le moteur
    33. 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. 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. 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. 36 End User Monitoring
    37. 37. 37 End User Monitoring
    38. 38. 38 End User Monitoring
    39. 39. 39 End User Monitoring
    40. 40. 40 Démo ! End User Monitoring
    41. 41. 41 Etape #4: Automatiser
    42. 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. 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. 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. 45 Architecture Serveur Front Supervision Tomcat Metrics Injecteur Agent AppD IC
    46. 46. 46 Démo ! Automatisation
    47. 47. 47 Plugin Gatling pour Jenkins 1/3
    48. 48. 48 Plugin Gatling pour Jenkins 2/3
    49. 49. 49 Plugin Gatling pour Jenkins 3/3
    50. 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. 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. 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. 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. 54 Si vous ne deviez emporter que 3 messages…
    55. 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. 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. 57 > Message #3 Si ça fait mal, il faut le faire souvent èAutomatiser est la solution Conclusion
    58. 58. 58 Question ? Questions ?
    59. 59. 59 Au passage…

    ×