Perfug BOF devoxx2017.pptx

60 vues

Publié le

BOF du meetup Perfug à Devoxx 2017 : 35 sessions du Perfug en 35 minutes

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

  • Soyez le premier à aimer ceci

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

Aucune remarque pour cette diapositive

Perfug BOF devoxx2017.pptx

  1. 1. BOF Performance User Group
  2. 2. Le perfUG c’est : • Offrir un lieu d’échanges informels ouvert à toutes les personnes intéressées par l’optimisation et la performance, quel que soit leur niveau • Faciliter la diffusion des derniers outils et des meilleures techniques pour maîtriser la performance La session s’est terminée par : • Des éléments de méthode • Un hands-on pour mettre en pratique #1 Inauguration du Performance User Group par Henri Tremblay @henri_tremblay et Marc Bojoly @mbojoly
  3. 3. La mesure doit être au coeur de la démarche de performance Un outil : l’APM - Application Performance Management Un éditeur : AppDynamics qui s’est fait connaître par son adoption chez Netflix Une coding session pour visualiser : • Un appel à une application externe • Un Lock • Du context switching lié à des appels à la base de données #2 AppDynamics par Alexandre Méchain @Alexandremecha2 et Marc Bojoly @mbojoly
  4. 4. Évaluer les performances unitaires du système (CPU, RAM, I/O) pour • Choisir au mieux un composant technique ? • Tester une hypothèse d’architecture ou de tuning ? • Prévoir le capacity planning et le TCO Tester par comparaison avec de l’outillage simple : • CPU : openssl speed, sysbench • RAM : bandwidth • I/O : bonnie++, iozone • HTTP : apache benchmark, wrk #3 La perf système pour les nuls par Ludovic Piot @lpiot
  5. 5. Avec l’expérience beaucoup de problèmes de performance reviennent encore et encore Kirk Pepperdine, Java Champion a capitalisé sa connaissance dans l’outil Illuminate (ex-JClarity) Quelques exemples de problèmes classiques • Trop de Garbage Collection • Trop de context switching créé par des locks • Des attentes vers des systèmes externes • Trop peu de threads #4 JClarity (Illuminate) par Kirk Pepperdine @javaperftuning
  6. 6. Comprendre le réseau et sa performance : • Latence, bande passante, taux d’erreur, duplex, MTU, jitter Protocoles • UDP, TCP • Congestion windows & time to load Outils • ping, traceroute, tc… Tuning & tips • Linux : windows, MTU, slow-start • Attention : VPN, lazy joins, content ratio • Cache, réutilisation de connexions #5 NEED FOR SPEED: PACKET EDITION PRIMER TO NETWORK PERFORMANCE FOR NORMAL PEOPLE par Raphaël Luta @raphaelluta
  7. 7. Gatling est un outil pour simuler de la charge sur une application • En mode acteur • Avec un DSL scala en lieu et place d’une interface graphique • Mais avec un beau rapport de résultat Stéphane nous a ensuite présenté le fonctionnement interne de Gatling et les choix d’implémentation pour 2014 (à base de Monad) • l’API de validation à base de Monad • La nouvelle API session • Et plein d’autres (anciennes nouveautés) #6 Gatling par Stéphane Landelle @slandelle
  8. 8. Une session pratique sur Jprofiler avec une application truffée de bugs activables via JMX : • Un pool JDBC mal tuné • Une requête SQL qui renvoie la base entière • N+1 requêtes sur JPA • Des méthodes synchronized • Un pool de threads mal configuré dans le serveur d’application • Une fuite mémoire sur les sessions Tomcat • Beaucoup trop de logs • Trop exceptions ! • Un GC mal configuré • Un pool JDBC refait à la main • Et on n’a pas eu le temps de tout voir ! #7 JProfiler par Brice Leporini @blep et Florent Ramière @framiere
  9. 9. Une architecture innovante pour recevoir en temps réel des informations de capteur à haute fréquence Une approche event-driven, asynchrone, qui optimise l’utilisation du CPU en travaillant avec un seul thread Une stack Scala, Akka, MongoDB, MySQL Redis Des surprises : le système déborde ! Une architecture pour de très hautes volumétries : près de 5 000 msg/s. en mode asynchrone #8 La programmation Reactive par Emmanuel Fortin @fortemm et Philippe Prados @pprados
  10. 10. Prismic.io est un CMS stateless Il offre aux développeurs des API afin de récupérer le seul contenu nécessaire Son architecture sépare totalement la writing room de l’API pour pouvoir héberger rapidement en mode SaaS plusieurs milliers de repositories #9 Prismic.io par Guillaume Bort @guillaumebort et Sadek Drobi @sadache
  11. 11. Hadoop : un cluster de stockage (HDFS) et de traitement. Comment améliorer ses performances ? Un réseau dédié, des machines homogènes et MESUREZ ! MAP : • Blocs de 64 bits • Sérialisation • Format Colonnar pour ne récupérer qu’une partie des données • Eviter le spilling sur le disque REDUCE • Combiner, compression, partitionnement • Optimiser le nombre de threads pour récupérer les données • Eviter le spilling sur disque • Optimiser les RecordWriters • Préparer les data pour le requêtage (Hive) #10 Hadoop par Sofian Djamaa @sdjamaa
  12. 12. System.nanoTime() pour mesurer le temps d’exécution de votre méthode ? N’y pensez même pas ! Java Microbenchmarking Harness est conçu pour prendre en compte les optimisations de la JVM Il est important de bien prendre en main les exemples pour maîtriser les réglages possibles pour contourner les optimisations de la JVM (inlining, suppression de méthodes non utilisées…) Henri a terminé par un benchmark entre Easy Mock et Mockito #11 JMH par Henry Tremblay @henri_tremblay
  13. 13. Les CPU embarquent un Processor Monitoring Unit qui peut monitorer • Les cycles • Les instructions • Les caches • Les accès mémoire (et au cache) Outil linux : perf Perf list liste les compteurs disponibles (ex. LLC-Load-misses pour les cache misses) Overseer : librairie Java qui permet de programmer tous les compteurs disponibles et de profiler précisément des portions de code d’applications #12 Les Unités de mesure des CPU par Jean-Philippe Bempel @jpbempel
  14. 14. Comment optimiser basiquement les performances de son application web ? Au niveau serveur : • Concatenate, Compress, Cache Au niveau des images • Comprimer, utiliser les sprites Au niveau du javascript • Mettre <script> en base de page et utiliser les attributs defer et async Au niveau CSS • Limiter au maximum les reflow, et suivre quelques bonnes pratiques pour le parseur CSS Au niveau de la perception • On peut tricher ! .. #13 WebPerf par Timothée Carry @pixelastic
  15. 15. La finance de marché vulgarisée c’est comme un super marché : on va faire un Pasta Pricer ! Différents approches : mono-thread, multi-thread, pool de threads Comment rendre la programmation réactive accessible à tous et sans danger ? Avec la librairie Michonne qui encapsule 2 patterns • Sequencer • Conflation Conseil : éviter les buffers intermédiaires qui créent du retard Le réactif n’est pas une panacée, c’est une forme particulière de design #14 Latences basses, haut débit : Les secrets de la Finance pour avoir des systèmes réactifs par Thomas Pierrain @tpierrain et Cyrille Dupuydauby @Cyrdup
  16. 16. LoadRunner est l’outil de test de charge proposé par HP Proposé sous Windows, il offre un service complet de test de charge avec : • Un outil de capture • Un Virtual User Generator • Un outil de design pour le tir • Des machines d’injection • Un outil de collecte • Un outil d’analyse Le principal différenciant de Load Runner est son support de très nombreuses technologies (HTTP, Base de données, Ecran caractère…) LoadRunner offre une version gratuite jusqu’à 50 utilisateurs simultanés #15 HP Load Runner par Guillaume Alex
  17. 17. Dynatrace est un outil d’APM (Application Performance Management) Sa philosophie est de fournir la vision la plus détaillée possible tout en offrant une finesse de configuration pour limiter l’impact sur les performance Dynatrace s’étend avec une offre RUM (Real User Monitoring) avec des mesures de ressenti depuis le navigateur #16 Dynatrace pour monitorer vos problèmes de performance par Antonio Gomes Rodriguez @ra0077 Source : https://community.dynatrace.com/
  18. 18. #17 Phaser and StampedLock Concurrency synchronizers par Heinz Kabutz @heinzkabutz Les synchronizers • Maintiennent un état mutable cohérent • Encapsulent un état qui déterminent si le thread qui arrive doit attendre ou passer Comment utiliser les différents synchronizers • CountDownLatch (attention aux interruptions) • Phaser (plus simple à utiliser) • ReadWriteLock (Java 6) • ReentrantLock (attention au try/finally) • StampedLock (plus performant mais plus difficile à écrire) Comment bien utiliser les locks ? • Eviter au maximum les locks en écriture (cf. exemples)
  19. 19. #18 JDBC / JPA / Hibernate sans maîtrise la puissance n’est rien par Brice Leporini @blep JPA est largement utilisé dans les développements Java Mais les erreurs en matière de performance sont aussi très fréquentes Quelques florilèges des erreurs les plus fréquentes durant la session • La mauvaise compréhension du fonctionnement de l’entity manager • Le N+1 requêtes • La méconnaissance des Named Queries et de l’API criteria • Un pool JDBC mal configuré
  20. 20. #19 Fast Data Pipelines with Kafka par Sam Bessalah @samklr Kafka est un moteur de messaging distribué à fort débit, pub/sub, faible latence Pourquoi Kafka est rapide • Kernel Page Cache • Zero copy (Sendfile API) • Ecritures séquentielles • Dumb Brokers • Pulling Customers Performance Gotchas • Consumer Lag • Rebalancing
  21. 21. #20 Riemann par Yann Schwartz @abolibibelot Chez Criteo l’ingestion de logs pose des soucis d’échelle Graphite < 100 000 métriques par seconde Les solutions type rsyslog présentaient des limites en terme de souplesse et de performance Riemann est un event stream processor • Il n’est pas distribué • Il stocke aussi peu d’état que possible Il permet de traiter jusqu’à 200 000 métriques par seconde Il filtre, combine, modifie le flux pour comprendre le système Source : http://riemann.io
  22. 22. #21 Programmation lock free : les techniques des pro par Jean-Philippe Bempel @jpbempel Réduire la contention pour une meilleure scalabilité Mesure de la contention: JProfiler, JVMTI Stratégies : • CopyOnWrite • Lock Striping • Compare-And-Swap • Barrière mémoire Structures : • Disruptor : un Ring Buffer permettant d’avoir différentes stratégies (ex. N P, 1C) et très performant (lock-free, peu d’allocation) • JCTools : Files lock-free avec un degré fin de choix • OrderedScheduler : une structure lock free for garantir qu’un couple de traitements se fera dans le même ordre Les stratégies d’attendre • Wait (latence) • Spin (faible latence mais brûle un core)
  23. 23. #22 NGNIX par Bastien Fiorentino JVM OFF-HEAP et architecture NUMA par Gaëlle Guimezanes @gguimezanes Un serveur en France. Des clients en Asie. 7 s. De temps de réponse 586 ms. de latence réseau Comment optimiser simplement ? Avec un reverse proxy NGINX pour optimiser le nombre de connexions et en faisant du cache Au final 2 s. pour le chargement QuartetFS : plusieurs TB en mémoire et des serveurs NUMA Pour cela on stocke en off-heap en compressant les données (dictionnarisation) En NUMA la mémoire est partitionnée : comme en map reduce on fige des pools de threads responsables d’une partition et figés au plus prêt de la partition
  24. 24. #23 Les secrets de la JVM pour les algos à haute fréquence par Philippe Prados @pprados Un algorithme haute fréquence doit exploiter au mieux les architectures des processeurs : la mémoire, la gestion des verrous, les caches 1) L’assembleur 2) L’exploitation des caches 3) Compare and Set 4) Framework : Conteneurs immuables pour éviter l’éviction des caches, Transaction en mémoire 5) Autres : Affinité avec les sockets (OpenHFT), synchronize est optimisé 6) Conteneurs lock-free
  25. 25. #24 Deep into your native application par Fabien Arcellier @farcellier 2 types de profiling sur les applications natives • Le profiling par instrumentation (gprof, callgrind) : précis mais pénalisant ! • Le profiling par échantillonnage (perf, Oprofile, Intel VTune) : peu pénalisant mais on peut rater des éléments • Les outils à retenir : perf & flamegraph • Et une demo !
  26. 26. #25 HTTP the next generation par Raphaël Luta @raphaelluta HTTP est le protocole applicatif le plus populaire bien qu’il soit lent inefficace et complexe HTTP la suite : Server-sent event Websocket… avec une compatibilité faible HTTP/2 : • Trames binaires • Compression des headers • Multiplexing de flux sur une connexion TCP Gain typique de l’ordre de 20% Utilisation avancées possibles : contrôle de cache client, priorisation, messaging asynchrone Async messaging mais non compatible avec les WebSockets QUIC : HTTP/2 over UDP
  27. 27. #26 Measuring Front-End performance par Gareth Hughes High performance image par Tobias Baldauf (@tbaldauf) Décidez en amont de vos objectifs de performance d’affichage à atteindre A toute les phase du cycle de développement mesures, instillez la culture de la performance En utilisant des outils de mesure et de reporting pour avoir agir à partir d’infos du terrrain (sondes, RUM, profilers) Les images sont la cause principale de lenteurs des sites Pour l’améliorer travailler le format ! Compressez vos JPEG avec mozjpeg et utilisez cjpeg-dessim ou Adept Suivez le développement de JPEG XTT
  28. 28. #27 Comment ne plus ajouter de RAM à vos JVM sans savoir pourquoi par Philippe Kernevez @pkernevez La gestion de la mémoire en Java : s’il y a une fuite mémoire c’est forcément qu’il est référencé dans le code 3 zones mémoires : Young/Tenured/Perm Un GC survient lors d’un échec d’allocation Lors d’un GC les objets survivants sont promus dans la zone suivante Tenured Promotion : des objets référencés par des objets déjà dans la zone tenured peuvent être promus à tort Une partie du GC est bloquant pour la JVM Des reference card sont posés lors de la création de références pour éviter d’avoir à parcourir toute la mémoire VisualVM • Permet de visualiser les GC et leur évolution • En direct seulement HPJMeter (gratuit) ou Censum (payant) • Permet d’analyser les logs GC sur des temps plus long • Visualise le taux d’allocation, les quantités mémoires avant/après, la distribution des objets par génération... MemoryAnalyzer • Permet d’analyser des heapdumps • Utiliser le dominator tree puis la liste des objets
  29. 29. #28 Comment tester et optimiser la performance d’un SI par Cyril Picat @cyrilpicat et Marc Bojoly @mbojoly REX d’un projet de migration de SI bancaire 1 : chasser les idées reçues 2 : s’adapter à la réalité - des outils simples (analyse de logs, outils système) - et quelques pré-requis intangibles (environnement opérationnel isolé, un jeu de données minimal) 3 : cadrer le chantier face à des problèmes vertigineux 4 : tester les systèmes indépendamment pour réduire la complexité 5 : utilisez intelligemment les tests de charge et d’autres outils 6 : quelques tests end-to-end sont indispensables mais restez simple (ex. Pic de transaction, rejeu d’une journée)
  30. 30. #29 Créer une API distribuée mondialement sans utiliser (ou presque) le cloud par Sylvain Utard @sylvainutard Algolia : un search as a service pour l’intégrer dans son site web. La performance est dans l’ADN d’Algolia (11 milliards de recherches utilisateurs par mois, 36 datacenters et 400 machines) Hautement disponible grâce des un cluster de 3 machines en réplication master master (consensus distribué implémenté avec RAFT) Sans load balancer ! C’est le client qui le fait L’index est également répliqué dans différents datacenters répartis dans le monde Choix du bare-metal • Besoin d’un CPU peu courant (8 à 12 threads) au moins 3,5 GHz - Intel E5-1650v3 • RAM ECC 1600 ou 2400 MHz. • SSD Intel S3710 : les disques mourraient tous les 3 mois • Réseau : il faut pouvoir choisir la localisation des machines ! Le Cloud avec ces contraintes : beaucoup trop cher ! • AWS : 1700 $ /mois • Provider classique : 160 ou 385 $ / mois Mais beaucoup plus de contraintes opérationnelles
  31. 31. #30 Scalding par Sofian Djamaa @sdjamaa Scalding : une API Scala pour écrire du MapReduce • Au dessus de cascading et Hadoop MapReduce Scalding fait un plan d’exécution pour réduire le nombre de jobs map/reduce La réécriture de la requête permet de le réduire encore plus • Optimiser avec des combiners (sommes les clés en local) • Traiter en mémoire ce qui est possible On optimise ensuite les reducers • Optimiser le nombre de reducers • Vérifier que les traitements se font en mémoire
  32. 32. #31 Latency: from dream to nightmare in 100 ms. par Adam Surak @AdamSurak Latence Paris New-York : 39 ms. en théorie, 85 ms. en pratique Les millisecondes sont importantes pour un moteur de recherche comme Algolia Leur donnée est répliquée 3 fois dont 2 fois de façon asynchrone dans un autre datacenter Mais Internet n’est pas optimisé pour la latence • Il ne suit pas la géographie • Il est fortement asymétrique Ce sont des problèmes complexes à résoudre : c’est toujours le problème des autres Monitorer toujours votre réseau
  33. 33. #32 OutOfMemoryException : quel est le coût des objets en Java par Jean-Philippe Bempel @jpbempel Comment diagnostiquer des problèmes mémoire liés à la taille des objets ? java.lang.Object (header pour tous les objets) : 16 bytes en 64 bits CompressedOops : stockage de l’adresse sur 32 bits jusqu’à 32 GB de mémoire Padding : espace perdu ! (alignement par 8 bytes = 64 bits) Un outil Java Object Layout Diagnostic & War Stories 20 GB de HashEntries ! 18 GB de String[] Measure, don’t premature
  34. 34. #33 Guide de survie d’un développeur dans une application qui rame par Brice Leporini @blep Collecter les données de l’environnement concerné Si vous soupçonner des problèmes mémoire: jstat -gcutil Et apprenez à maîtriser le GC ! Si la mémoire est trop grosse jmap - dump… + Memory Analyzer Tool Sinon il faut savoir ce que fait l’application jstack <pid> + Thread Dump Analyzer Tuner votre pool de threads Enfin vérifier les IO (disque ou requêtes SQL)
  35. 35. #34 GPGPU en .NET par Mick Philippon @MickPhilippon GPGPU : le processeur des cartes graphique Optimisé pour réalisé en parallèle un très grand nombre de calculs (sur les shaders normalement) Peut être détourné pour faire du calcul intensif Algorithme de Krager : un algorithme probabiliste pour déterminer la coupe minimale dans un graph Demo en C# avec Cudafy.net Réponse : le GPGPU n’est pas adapté pour ce type de calcul Beaucoup plus efficace pour faire le même calcul sur des données de taille fixe fonction contraction(G=(V,E)): tant que |V| > 2 choisir e dans E aléatoirement (*fonction aléatoire uniforme*) G ← G/e retouner l'unique coupure de G Source : https://fr.wikipedia.org/wiki/Algorithme_de_Karger
  36. 36. #35 WebPerf : quoi de neuf ? par Stéphane Rios @stefounet Comment afficher quelque chose d’utile le plus rapidement possible Des règles de base écrites avant le mobile ! Latence mobile : 3G 200 - 3500 ms. Pour aller plus loin • Cacher • JS asynchrone ou defer • Lazyloading • Chargement asynchrone de font • Et HTTP/2 QUIC pour remplacer TCP Services Workers : à creuser pour optimiser les appels réseau Optimiser TLS Nouveaux formats d’image : MozJPEG, DSSIM Nouvelles règles : • Preloader : le navigateur va essayer de précharger les objets. Ne pas lui masquer • Concaténation : trouver un intermédiaire (taille, maintenabilité) • Sharding des objets statiques : attention à la latence DNS • Lazy loading: à limiter aux images en dessous de la ligne de flotaison • JS en bas : le remplacer par des JS asynchrone • Minification : BOF
  37. 37. Vous en voulez encore ?
  38. 38. #36 HTTP/2 pour (micro)-services par Raphaël Luta @raphaelluta HTTP/2 est-ce utile dans mon datacenter ? Avantages HTTP/2 : binaire, headers compressés, multiplexing et push server h2c : HTTP/2 sans SSL Architecture cible : proxies et serveurs HTTP/2 : les requêtes peuvent être mélangées (contrairement au HTTP/1 pipelining) Sur HTTP/1.1 en serial les requêtes s’accumulent Mais en HTTP/2 c’est plus dur à tuner
  39. 39. Et pourquoi pas vous ? Intéressés ? Consultez • @PerfugParis • http://perfug.github.io –Avec les vidéos des sessions Intéressez pour nous aider ? • Venez speaker • Proposez nous des speaker

×