Oxalide Morning Tech #2 - Démarche performance

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

Transcript

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ées 1 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’utilisateurs 3 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 Where needed!
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-CI 0 • Scripts de démarrage cloud-init • Déclenchement de CodeDeploy
60. Questions ? Réponses…