Morning tech #2 - Démarche performance slides

Morning Tech #2Démarche de performance

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

Contactez-nous à [email protected] !

Speakers

Adrien le PriolITWO Customer Team 1

@Priolix @lpiot

Ludovic PiotResp. du pôle Conseil,

Architecture et DevOps

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

Performance Web :les enjeux

I amar prestar aenThe world has changed…

- Galadriel

source : Warner Bros & NewLine Cinema

Le monde a changé

SOcial

LOcal

MObile

+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

+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

Statistiques d’usage d’Internet en 2016

source : https://hostingfacts.com/internet-facts-stats-2016/

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…

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

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/

Les différentes composantes de la performance d’un site Web

Navigateur Web

Cache

Moteur JS

InterpréteurHTML

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’échangeStockage 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…

Performance Web :les bonnes pratiques

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)

Limiter le trafic non-monétisable

Robot.txt

User-agent: ArchitextSpiderDisallow: *

Améliorer le référencement

Bloquer le référencement de certaines ressources.

Déclaratif

Limiter le trafic non-monétisable

GeoIP filtering

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

ApacheNginxVarnish (4.0 - 4.1 - 5.0, 3.0)IIS module (ASP.Net)Wordpress plugin

DATADOME

Perception d’un chargement rapide… ou pas…

Architecture applicative & physique

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

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

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

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

Optimiser la taille/nombre des images

Minifier CSS/JS

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

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/csstext/plain text/xml text/css text/javascript application/javascript

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>

Exécuter les JS en fin de chargement

Et prioriser les CSS

HTML

JS CSSBlocks parsing Blocks rendering

...

Exécuter les JS en fin de chargement

Et prioriser les CSS

HTML

JS CSSBlocks parsing Blocks rendering

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>

Fainéantise

Lazy-load

Lazy-load:

1. Bande passante2. Rapidité3. Gaspillage

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

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

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

Protocole HTTP/2

Protocole HTTP/2

Performance Web :l’obsession de la mesure

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/

Les tests de charge

Différents types de test de charge

Objectif : mesurer la performance unitaireEx. : 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 cibleEx. : on simule l’utilisation de l’application par 200 utilisateurs en parallèle pendant 2 heures.

Objectif : déterminer les limites de l’applicationEx. : 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 étendueEx. : on simule l’utilisation de l’application pendant 48h, avec une charge constante et égale à la charge moyenne.

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.

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étriquesContrôleur

Rapport d’analyse

Rapport de test

char

ge

monitoring

pilotage

Injecteurs

Exécution : simulation d’utilisateurs3

Application cible

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)

Gatling

Exemple Scala

Gatling

Exemple Scala

Gatling

Options de lancement

Tests de charge

Les outils : Gatling - NewRelic

Performance Web :la démarche PDCA

Premature optimization is the root of all evil

- Donald Knuth

L’optimisation ne vaut que par l’expérimentation

Code

Measure

Optimize

Where needed!

Les tests de perf dans un cycle projet

Mode Waterfall

PROD

ArchiDev

Perf

Les tests de perf dans un cycle projet

Mode agile

PROD

ArchiDev

Perf

1. Conception des tests

2. Automatisation des tests

3. Développement logiciel

#1 #2 #3

4. Exécution auto- matique des tests

Les tests de perf dans un cycle projet

Mode “dans la vraie vie”

PROD

ArchiDev

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élaiOPTIMISATIONS

COMME ON PEUT

Les tests de perf dans un cycle projet

Mode “Etat de l’art”

PROD

ArchiDev

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

2

1

34

AMI

0

Cloud-init

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

Questions ?Réponses…