Oxalide MorningTech #2 - Démarche de performance 2ème MorningTech @Oxalide, animé par Adrien Le Priol (@Priolix) et Ludovic Piot (@lpiot), le 28 février 2017. Une vue d'ensemble sur la démarche et les outils pour aborder et maîtriser la performance de son site Web. En 2012, Amazon publiait une étude indiquant que chaque seconde de performance perdue sur son site de commerce lui coûtait $1.6 milliards de chiffre d'affaire. Par delà ce chiffre colossal avancé par le géant du Web, il est une réalité business : plus un site est lent, et moins les utilisateurs sont enclin à naviguer dessus. Les smartphones et le SoLoMo exacerbent cette réalité avec encore plus depuis 10 ans maintenant. Sur le terrain, l'architecture technique des sites Web, de plus en plus complexe, rendent ses performances impossibles à prédire : complexité des développements applicatifs, multitude des composants impliqués dans l'architecture technique, recours à des services tiers (issus du SI de votre entreprise, ou de services tiers), big data, machine learning… Une seule façon de prédire les performances : tester… en situation réelle. A travers les différentes étapes d'une démarche d'optimisation des performances d'un site Web, les enjeux et les écueils d'une telle démarche vous seront détaillés. Subject: Oxalide's MorningTech talk about an overview of how to deal with performance in a Web site. Date: 28-feb-2017 Speakers: Adrien Le Priol (@Priolix, @Oxalide) and Ludovic Piot (@lpiot, @Oxalide) Language: french Lien SpeakerDeck : https://speakerdeck.com/lpiot/oxalide-morning-tech-number-2-demarche-performance Lien SlideShare : https://www.slideshare.net/LudovicPiot/morning-tech-2-demarche-performance-slides YouTube Video capture: https://youtu.be/a8jSbvyBzYU Main topics: * Les enjeux de la performance d'un site Web * Les différents éléments de performance d'un site Web ** Infrastructure, architecture technique, tuning, architecture applicative, WebPerf * L'obsession de la mesure * Les outils * Les quickwins ** Caches, upscaling, outscaling, sharding * La démarche de test de charge ** Méthodologie, outils, types de test, données de test * La démarche PDCA ** Intégrer les tests de charge au cycle de développement ** Environnement éphémère * Questions / Réponses

1. Morning Tech #2
Démarche de performance

2. Les événements Oxalide
• Objectif : présentation d’une thématique métier ou technique
• Tout public : 80 à 100 personnes
• Déroulé : 1 soir par trimestre de 18h à 21h
• Introduction de la thématique par un partenaire
• Tour de table avec des clients et non clients
• Echange convivial autour d’un apéritif dînatoire
• Objectif : présentation d’une technologie
• Réservé aux clients : public technique avec laptop – 30 personnes
• Déroulé : 1 matinée par trimestre de 9h à 13h
• Présentation de la technologie
• Tuto pour la configuration en ligne de commande
• Objectif : présentation d’une thématique métier ou technique
• Réservé aux clients : 30 personnes
• Déroulé : 1 matin par trimestre de 9h à 12h
• Big picture
• Démonstration et retour d’expérience
Apérotech
Workshop
Morning Tech

3. Contactez-nous à job@oxalide.com
recrute !

4. Speakers
Adrien le Priol
ITWO Customer Team 1
@Priolix @lpiot
Ludovic Piot
Resp. du pôle Conseil,
Architecture et DevOps

5. Introduction
● Les enjeux de la performance sur le Web
● Les différents éléments de performance d'un
site Web
Les bonnes pratiques
● Limiter le trafic non monétisable
● Infrastructure (HTTP/2 HTTPs, architecture
technique, tuning, architecture applicative,
WebPerf
● AMP by Google
● Les quickwins par grands thèmes
(infra / archi tech / archi appli / WebPerf)
● compression gzip, taille des images…
cas de Leroy-Merlin (règles de 10 images de
100 Ko maxi).
● Caches, upscaling, outscaling, sharding
Agenda
L’obsession de la mesure
● Les outils
● La démarche de test de charge
● Méthodologie, outils, types de test, données de
test
La démarche PDCA
● Intégrer les tests de charge au cycle de
développement (tests de non-regression)
● Environnements éphémères

6. Performance Web :
les enjeux

7. I amar prestar aen
The world has changed…
- Galadriel
source : Warner Bros & NewLine Cinema

8. Le monde a changé
SO
cial
LO
cal
MO
bile

9. +1 second could cost Amazon
$1.6 Billion in Sales
source : https://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales

10. +0.4 second and Google could lose
8 millions searches per day
source : https://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales

11. Statistiques d’usage d’Internet en 2016
source : https://hostingfacts.com/internet-facts-stats-2016/

12. Pour ce qui est des performances, les
développeurs pensent souvent avoir
livré ça…
En réalité, assez souvent, quand on le
fait tourner en production, ça
ressemble plutôt à ça…

13. Les enjeux de la performance sur le Web
Les performances d’un
système sont une
spécification fonctionnelle
implicite du système.
source : http://www.arthursclipart.org

14. Les enjeux de la performance sur le Web
La performance du
système doit être une
préoccupation
perpétuelle du cycle de
développement.
source : http://www.geantsduweb.com/

15. Les différentes composantes de la performance d’un site Web
Navigateur Web
Cache
Moteur JS
Interpréteur
HTML
Connexions
HTTP
Equipements
réseau
Serveur DNS
Routeurs
Firewall
Proxies
Serveur Cache
Statiques
Config.
Routage
backends
Refactoring
HTML
Serveur Web
Workers
Config.
Rewrite
ruless
Redirect
Reverse-Proxy
Algo. TLS
ACL
Rewrite rules
Protocoles
HTTP
Serveur App
Workers
Config.
Protocole d’
échange
Stockage
statiques
Message broker
Queues
TTL
Protocole d’
échange
Patterns de
diffusion
App
Sync / Async
Cache appli.
Langage
Qualité du
code
Plateforme
load-balance
# instances
sizing & unit
perfs
Tuning
Base de données
Size
Cache
Sharding
Stats /
Explain plan
My Platform… well… sort of…

16. Performance Web :
les bonnes pratiques

17. Identifier le trafic monétisable
Connaître son auditoire.
Éliminer les parasites:
outils d’intelligence concurrentielle
bases de données marketing
monitoring média, clipping
agences SEO
Badbots*
*les bad bots représentaient jusqu’à 35% du nombre total de visites - (source : Datadome)

18. Limiter le trafic non-monétisable
Robot.txt
User-agent: ArchitextSpider
Disallow: *
Améliorer le référencement
Bloquer le référencement de certaines ressources.
Déclaratif

19. Limiter le trafic non-monétisable
GeoIP filtering

20. Limiter le trafic non-monétisable
Solutions SaaS : Datadome
Quoi
● User agent
● IP owner
● Géolocalisation
Comment
● Nombre de hits par adresse IP
● Vitesse de crawl
● Récurrence des hits
● Nombre de hits générant des erreurs 404
● Cookies
Apache
Nginx
Varnish (4.0 - 4.1 - 5.0, 3.0)
IIS module (ASP.Net)
Wordpress plugin
DATADOME

21. Perception d’un chargement rapide… ou pas…

22. Architecture applicative & physique

23. Web perf : priorité au client… et à l’affichage

24. Web perf : priorité au client… et à l’affichage

26. Web perf : priorité au client… et à l’affichage

27. Quickwin
& bon sens
Optimiser la taille/nombre des images
Minifier CSS/JS
Activer le Gzip
Exécuter les JS en fin de chargement
Limiter les ressources externes (JS, annonceurs, statistiques … )

28. Optimiser la taille/nombre des images

29. Minifier CSS/JS

30. Les Headers
Piloter les caches
ETag:"e7d8e34a27cb1b77c9114da75ca21397"
Expires:Tue, 28 Feb 2017 01:33:01 GMT
Last-Modified:Sun, 04 Sep 2016 03:08:00 GMT
Piloter le cache :
● Navigateur
● Varnish
● CDN

31. Activer Gzip
Apache
<IfModule mod_deflate.c>
AddOutputFilterByType
DEFLATE text/html
text/plain text/xml
text/css
text/javascript
application/javascript
</IfModule>
Varnish
if (beresp.http.content-type ~ "text") {
set beresp.do_gzip = true;
}
Non conseillé
Nginx
gzip on;
gzip_types text/css
text/plain text/xml text/css
text/javascript
application/javascript

32. Activer Gzip
<IfModule mod_headers.c>
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}.gz" "-s"
RewriteRule "^(.*).css" "$1.css.gz" [QSA]
RewriteRule ".css.gz$" "-" [T=text/css,E=no-gzip:1]
<FilesMatch "(.js.gz|.css.gz)$">
Header append Content-Encoding gzip
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>

33. Exécuter les JS en fin de chargement
Et prioriser les CSS
HTML
JS CSS
Blocks parsing Blocks rendering
...

34. Exécuter les JS en fin de chargement
Et prioriser les CSS
HTML
JS CSS
Blocks parsing Blocks rendering

35. Limiter les ressources externes
(JS, annonceurs, statistiques … )
● Appels DNS
● Réduire le nombre de syn/ack
● Bande passante
● limiter les redirections
Préfetch DNS resoltion:
<html>
<head>
<link rel="dns-prefetch"
href="//www.domain1.com">
<link rel="dns-prefetch"
href="//www.domain2.com">
</head>
<body>
<img src="www.domain1.com/image1.jpeg">
<script src="www.domain2.com/script1.js">
</body>
</html>

36. Fainéantise
Lazy-load
Lazy-load:
1. Bande passante
2. Rapidité
3. Gaspillage

37. Triche
● 0-200ms instante i made good
● 200 - 1000ms Computer compture its
● 1s+ I'm waiting ...
● 10+ I'm gone
1. Spinner
2. Ecran de transition
3. Substitution

38. Triche
● 0-200ms instante i made good
● 200 - 1000ms Computer compture its
● 1s+ I'm waiting ...
● 10+ I'm gone
1. Spinner
2. Ecran de transition
3. Substitution

39. Triche
● 0-200ms instante i made good
● 200 - 1000ms Computer compture its
● 1s+ I'm waiting ...
● 10+ I'm gone
1. Spinner
2. Ecran de transition
3. Substitution

40. Protocole HTTP/2

41. Protocole HTTP/2

42. Performance Web :
l’obsession de la mesure

43. L’obsession de la mesure
La mesure de
performance doit être au
cœur du processus de
développement
informatique.
source : http://www.geantsduweb.com/

44. Les tests de charge
Différents types de test de charge
Objectif : mesurer la performance unitaire
Ex. : le use case de souscription est testé pour 1 utilisateur et, pour chaque étape du use
case, on mesure le temps passé dans les différents composants de l’application.
Test de
performance
unitaire
Test de
charge
Test de
rupture
Test de
vieillissement
Objectif : mesurer la tenue en charge de l’application sur la population cible
Ex. : on simule l’utilisation de l’application par 200 utilisateurs en parallèle pendant 2 heures.
Objectif : déterminer les limites de l’application
Ex. : on augmente le nombre d’utilisateurs en parallèle sur l’application jusqu’à ce que le
taux d’erreurs / les temps de réponse ne soient plus acceptables.
Objectif : déterminer la capacité de l’application à fonctionner sur une période étendue
Ex. : on simule l’utilisation de l’application pendant 48h, avec une charge constante et égale
à la charge moyenne.

45. Tests de charge
But:
Connaître les limites de la plateforme
Déterminer les goulets d’étranglement
Optimiser le paramétrage middleware et applicatif
Cibler d'éventuelles anomalies de conception logiciel,
architecture.

46. Méthodologie d’un tir de charge
Définition du plan et
des cas de test
Création des scénarii et
des scripts de tests
Enregistrement des
métriques
Consolidation des
métriques et édition
d’un rapport de test
Analyse du rapport de
test et émission des
préconisations
1
2
3
4
5
Plan de test Cas de test Création des
paliers de données1
Scripts de test Scénarii de test
Capture des
métriques
Données de test
3
Métriques
Contrôleur
Rapport d’analyse
Rapport de test
charge
monitoring
pilotage
Injecteurs
Exécution : simulation
d’utilisateurs3
Application cible

47. Tests de charge
Qualité du tir de charge
dépend que la qualité du
scénario
Connaître le comportement
de ses utilisateurs (RUM:
Google analytics, Newrelic)

48. Gatling
Exemple Scala

49. Gatling
Exemple Scala

50. Gatling
Options de lancement

51. Tests de charge
Les outils : Gatling - NewRelic

52. Performance Web :
la démarche PDCA

53. Premature optimization is the root
of all evil
- Donald Knuth

54. L’optimisation ne vaut que par l’expérimentation
Code
Measure
Optimize
Whereneeded!

55. Les tests de perf dans un cycle projet
Mode Waterfall
PROD
Archi
Dev
Perf

56. Les tests de perf dans un cycle projet
Mode agile
PROD
Archi
Dev
Perf
1. Conception
des tests
2. Automatisation
des tests
3. Développement
logiciel
#1 #2 #3
4. Exécution auto-
matique des tests

57. Les tests de perf dans un cycle projet
Mode “dans la vraie vie”
PROD
Archi
Dev
Perf
1. Conception
des tests
2. Automatisation
des tests
3. Développement
logiciel
#1 #2 #3
4. Exécution auto-
matique des tests
PERFORMANCES
CATASTROPHIQUES
MEP À L’ARRACHE
Délai
OPTIMISATIONS
COMME ON PEUT

58. Les tests de perf dans un cycle projet
Mode “Etat de l’art”
PROD
Archi
Dev
Tests de charge en continu
1. Conception
des tests
2. Automatisation
des tests
3. Développement
logiciel
#1 #2 #3
4. Exécution auto-
matique des tests

59. 2
1
3
4
AMI
0
Cloud-init
EC2
Chef-solo CodeDeploy
ECR
S3 bucket
Tirs de performance automatisés
Environnements éphémères
1
• Terraform provisionne des instances EC2 sur AWS
(accès via SSH possible)
• Utilisation d’AMIs spécifiques enrichies avec un chef-solo
2
3
• CodeDeploy déclenche l’exécution de Chef-solo
• Chef-solo récupère les cookbooks sur un bucket S3
• Installation des packages et configuration OS +
middleware
4
• CodeDeploy lance le déploiement de l’application
• Récupération des artefacts applicatifs sur des dépôts (git,
nexus, registry Docker)
• Déploiement de l’application
5 • Déclenchement des scénarios Gatling
• job lancé en automatique via un pipeline Gitlab-CI0
• Scripts de démarrage cloud-init
• Déclenchement de CodeDeploy

60. Questions ?
Réponses…