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

985 views

Published on

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)

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

"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…

×