Université de la performance - Devoxx France

11

Tél : +33 (0)1 58 56 10 00

Fax : +33 (0)1 58 56 10 01

www.octo.com© OCTO 2014

50, avenue des Champs-Elysées

75008 Paris - FRANCE

Université de la

Performance

22

Tél : +33 (0)1 58 56 10 00

Fax : +33 (0)1 58 56 10 01

www.octo.com© OCTO 2014

50, avenue des Champs-Elysées

75008 Paris - FRANCE

Agenda

33

44

Applicatif Système

55

66

Développement Production

77

Méthodologie

88

DÉMO

99

Pause

2x10 minutes

1010

Tél : +33 (0)1 58 56 10 00

Fax : +33 (0)1 58 56 10 01

www.octo.com© OCTO 2014

50, avenue des Champs-Elysées

75008 Paris - FRANCE

Présentation de

l’équipe

1111

Architecte Senior

Responsable pôle

performance

Responsable R&D

Membre fondateur du PerfUG

Marc Bojoly

1212

Architecte Senior

Référent technique pôle

performance

Responsable R&D

EasyMock lead developer

Objenesis lead developer

Membre fondateur du PerfUG

Henri Tremblay

1313

Architecte Senior

Pôle Devops

Expert optimisation système

Co-organisateur du concours

de performance Billion-user

challenge en 2011

Intervenant PerfUG

Ludovic Piot

1414

Architecte

Expert Infra & Devops

Responsable de l’infrastructure

OCTO

Commiter :

Master-chef

Master-cap

Mikaël Robert

1515

Les performances d’un

système sont une

spécification

fonctionnelle implicite

du système

Notre vision ?

Source : www.arthursclipart.org

1616

La mesure de performance

doit être au cœur du

processus de

développement

informatique

Notre vision ?

Source : Les géants du Web

1717

Nous voulons des systèmes

performants

Notre vision ?

Source : Les géants du Web

1818

La démarche de test que nous utilisons

TESTS DE CHARGE

MesurerOptimiser

TESTS DE PERFORMANCE

UNITAIRE

1919

La démarche de test que nous utilisons

TESTS DE CHARGE

TESTS DE PERFORMANCE

UNITAIRE

MesurerOptimiser

Mise en place

des mesures

et scénarios

Exécution des

scénarios

• Simulation

• Correction

• Mesure

Optimisation

Estimation des

gains potentiels

• Sur un poste de

développement

• Validation des

hypothèses

• Tuning des « hot

spots »

• Environnements de

production

• Scénarios

représentatifs

• Jeux de données

• Cible à atteindre

2020

Définition du plan et des cas de test

Plan de test 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 Rapport d’analyse

Métriques

Rapport de test

Contrôleur

Scripts de test Scénarii de test

Capture des métriques

Application cible

Injecteurs

Données de test

Création des paliers de données

Exécution : simulation d’utilisateurs

Méthodologie d’un test de charge

1 1

2

3

3

3

4

5

2121

Les outils utilisés aujourd’hui

Identifier les ressources en quantité limitante

Identifier les impacts sur les différentes machines lorsque l’application est distribuée

Corréler l’évolution des temps de réponse et les consommations de ressources sur les différentes machines

Enregistrer et rejouer de manière fidèle un ensemble d’actions utilisateurs.

Variabiliser ces actions utilisateurs pour être représentatif de l’usage réel

Simuler un grand nombre d’utilisateurs

Migrer les données depuis la production mais il faut souvent l’anonymiser.

Générer un jeux de données mais il doit être représentatif

Rétablir le jeux de données dans son état initial une fois le tir effectué

GÉNÉRER LES DONNÉES

TESTER EN CHARGE

MONITORER LA CONSOMMATION DE

RESSOURCES

2222

Les outils en général

Identifier les ressources en quantité limitante

Identifier les impacts sur les différentes machines lorsque l’application est distribuée

Corréler l’évolution des temps de réponse et les consommations de ressources sur les différentes machines

Enregistrer et rejouer de manière fidèle un ensemble d’actions utilisateurs.

Variabiliser ces actions utilisateurs pour être représentatif de l’usage réel

Simuler un grand nombre d’utilisateurs

Migrer les données depuis la production mais il faut souvent l’anonymiser.

Générer un jeux de données mais il doit être représentatif

Rétablir le jeux de données dans son état initial une fois le tir effectué

GÉNÉRER LES DONNÉES

TESTER EN CHARGE

MONITORER LA CONSOMMATION DE

RESSOURCES

2323

Notre fil rouge : Happy Store

Navigateur Tomcat PgSQL

Une application comme on en

rencontre souvent, pas très loin de

l’état de l’art.. Sauf pour les

performances !

2424

Architecture

APPLICATION SERVER

DATABASE SERVER

JVM

PostgreSQL

Tomcat

2525

Acheter des produits

http://localhost:8080/happystore/transaction?

countryCode=FRA&productId=1234&storeId=1234

http://localhost:8080/happystore/transaction?

countryCode=FRA&productId=1234&storeId=1234&txId=1

2626

Finaliser sa commande

http://localhost:8080/happystore/total?

txId=1

Total

2727

Calcul de l’inventaire sur un magasin

Inventory

http://localhost:8080/happystore/inventory?

storeId=1234

2828

Calcul du chiffre d’affaire par groupe de produits

Turnover

(group by+order by)

http://localhost:8080/happystore/turnover?

groupId=1

2929

LES DIFFÉRENTS TYPES DE TEST

•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

•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 2h

Test de charge

•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

Test de rupture

•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

Test de vieillissement

3030

DÉMO

Exécution test unitaire

3131

LES DIFFÉRENTS TYPES DE TEST

•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

•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 2h

Test de charge

•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

Test de rupture

•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

Test de vieillissement

3232

Cible de performance

Cible : 100 utilisateurs concurrents

Volumétrie de la base de données : 19,5 millions de lignes

3333

DÉMO

Remplissage des données

3434

Architecture

LOCAL SERVER APPLICATION SERVER

DATABASE SERVER

Gatling

PostgreSQL

JVM

Tomcat

3535

DÉMO

Exécution test de charge

3636

Premature optimization is the

root of all evil - Donald Knuth

3737

Il voulait dire ça:

// Do not use the for(Object o : list)

// because I think it is probably

// slower than doing this… Probably…

for(int i = 0; i < list.size(); i++) {

Object o = list.get(i);

…

}

Stop guessing dam it!!!

3838

Code

Mesure

OptimiseLà où

c’est

important

3939

PROD

Archi

Dev

Perf

4040

PROD

Archi

Dev

Perf

1. Conception

des tests

2. Automatisation

des tests

3. Développement

logiciel

4. Exécution auto-

matique des tests#1 #2 #3

4141

Archi

Dev

Perf

PROD

DélaiMEP À L’ARRACHE

1. Conception

des tests

2. Automatisation

des tests

3. Développement

logiciel

4. Exécution auto-

matique des tests#1 #2 #3

4242

1. Conception

des tests

2. Automatisation

des tests

3. Développement

logiciel

4. Exécution auto-

matique des tests#1 #2 #3

PROD

Archi

Dev

Tests de charge en continue

4343

Intégrer les tests de performances au cycle de

développement?

Hyperviseur

Jenkins

AppServer

Chef

DbServer

Chef

1

3

2

Créer environnement

Tir de performance

Destruction environnement

4444

Jenkins

Deploiement d’environnement automatisé : exemple avec Chef & Capistrano

GitNexus

Capistrano

Node

Chef

Hyperviseur

API hyperviseurNode

Chef

Node

Chef

Dép. app.

2

1

1

3

• Capistrano demande VM à l’hyperviseur

• Installation OS par PXE ou clone

2 • Création & mise à disposition VMs

• SSH ouvert, IP temporaire

3• Scripts de démarrage (maison, cloud-init…)

• Personnalisation VM, IP, Reseau etc

• Installation Chef

4

4

4• Capistrano lance Chef sur Node

• Chef récupère les cookbooks via Git

• Installation packages et configurations

5

5

5• Capistrano lance déploiement application

• Exécute sur machine téléchargement application

• Déploie application

• Administrateur

lance job0

4545

DÉMO

Automatisation des tests

4646

LES DIFFÉRENTS TYPES DE TEST

•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

•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 2h

Test de charge

•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

Test de rupture

•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

Test de vieillissement

4747

DÉMO

Test de rupture

4848

Architecture

TOOL SERVER APPLICATION SERVER

DATABASE SERVER

CI STACK

GRAPHITE STACK

Jenkins Gatling

Maven

Graphite

Collectd

Carbon

Git

Collectd

WhisperPostgreSQL

JVM

Tomcat

4949

DÉMO

Metrics

5050

Un exemple d’outil d’APM du marché : AppDynamics

5151

DÉMO

Tuning

5252

Bonnie++

5353

LES DIFFÉRENTS TYPES DE TEST

•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

•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 2h

Test de charge

•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

Test de rupture

•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

Test de vieillissement

5454

DÉMO

Test d’endurance

5555

Préparer les jeux de données Benerator

Exécuter une mesure unitaire Chrome developer tools

Identifier un problème d’index jstack, explan plan

Exécuter des tests de charge Gatling

Automatisation des tests de charge Jenkins, Capistrano, Chef

Problème de contention VisualVM, jstack

Mise en place du monitoring Metrics, collectd et Graphite

Tuning système Bonnie++

Identifier une fuite mémoire VisualVM

Résumé de la journée

5656

Exemple de benchmark:

http://blog.octo.com/lart-du-benchmark/

Conférence sur l’industrialisation (USI 2013):

https://www.youtube.com/watch?v=BXO3LYQ9Vic

Tests de performance SQLFire:

http://blog.octo.com/en/sqlfire-from-the-trenches/

Cet après-midi:

13h30: Hackergarten EasyMock

17h10: Microbenchmarking with JMH

Liens utiles

http://brownbaglunch.fr

5757

Retrouvez nous la semaine prochaine

http://perfug.github.io/

Prochain épisode: Jeudi 24 avril

Performance Hadoop temps réel

Sofian Djamaa (Criteo)

Sessions précédentes sur

le site

5858

5959

+Henri Tremblay

@henri_tremblay

htremblay@octo.com

+Marc Bojoly

@mbojoly

mbojoly@octo.com

+Mikael Robert

@mikaelrob

mrobert@octo.com

+Ludovic Piot

@lpiot

lpiot@octo.com