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

1. BOF Performance User Group

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. 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. É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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. #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. #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. #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. #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. #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. #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. #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. #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. #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. #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. #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. #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. #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. #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. #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. #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. #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. #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. #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. Vous en voulez encore ?

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. 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