université de la performance

1 1 1

Université de la Performance

2 2 Tél : +41 21 312 94 15 www.octo.com

© OCTO 2014

Avenue du théâtre 7 CH-1005 Lausanne - SUISSE

Présentation de l’équipe

3 3 3

Jean-Philippe Briend

! Software Architect ! Référent technique Pôle

Performance

! PerfUG Paris co-leader

! Opensource commiter

4 4 4

! Directeur Technique ! Référent technique pôle

performance

! OSSGTP Member

! JUGLausanne co-leader

! Commiter MOJO

Philippe Kernévez

5 5 Tél : +41 21 312 94 15 www.octo.com

© OCTO 2014

Avenue du théâtre 7 CH-1005 Lausanne - SUISSE

Agenda Test de

performance unitaire

Test de charge

Test de vieillissement Test de rupture

6 6 6

Applicatif Système

7 7 7

Développement Production

8 8 8

Méthodologie

9 9

DÉMO 9

10 10 10

DÉMO

11 11

Les performances d’un système sont une spécification fonctionnelle implicite du système

Notre vision ?

Source : www.arthursclipart.org

12 12

La mesure de performance doit être au cœur du processus de développement informatique

Notre vision ?

Source : Les géants du Web

13 13 13

LES 4 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

14 14 14

La démarche de test que nous utilisons Global vers Local puis Local vers Global

TESTS DE CHARGE

Mesurer Optimiser

TESTS DE PERFORMANCE UNITAIRE

15 15 15

La démarche de test que nous utilisons

TESTS DE CHARGE

Mesurer Optimiser

TESTS DE PERFORMANCE UNITAIRE

Scénarios +

Monitoring

Exécution des

scénarios

Optimisations Estimation gains

potentiels

•  Environnements de production

•  Scénarios représentatifs

•  Jeux de données •  Cible à atteindre

•  Simulation •  (Correction) •  Mesure •  Investigations

•  Sur un poste de développement

•  Validation des hypothèses

•  Tuning des « hot spots »

16 16 16

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

Application à tester

Injecteurs

Données de test

Création des jeux de données

Méthodologie d’un test de charge

1

2

3

Monitoring

3

Exécution 3

4

5

2

17 17 17

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

18 18 18

Les outils en général

HPJMeter Analyse de log GC

Profiling

Injection

APM

19 19 19

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 !

20 20 20

Architecture

APPLICATION SERVER

DATABASE SERVER

Architecture existante

JVM

PostgreSQL

Tomcat

21 21 21

Modèle de base de données

Store

Stock

Product Sales OperationCategory Family

VAT Country Sales Transaction1 0,n

0,n

0,n

10,n0,n 1

10,n1

1,n

1

0,n

1

0,n

22 22 22

Acheter des produits

23 23 23

Finaliser sa commande

Total

24 24 24

Calcul de l’inventaire sur un magasin

Inventory

25 25 25

Calcul du chiffre d’affaire par groupe de produits

Turnover (group by+order by)

26 26 26

Cible de performance

! Cible : 100 utilisateurs concurrents ! Volumétrie de la base de données : 13 millions de lignes

Store

Stock



0,n

0,n

10,n0,n 1

10,n1

1,n

1

0,n

1

0,n

260

1'000

10'000

3'000'000

10'000'000

0

1'0001'000

27 27 27

LES DIFFÉRENTS TYPES DE TEST



Test de performance

unitaire



Test de charge



Test de rupture




28 28

DÉMO 28

Exécution test unitaire

29 29 29

! Identifier la JVM

! Faire un threadump pendant la requête

Que fais le serveur applicatif pendant ce temps ?

30 30 30

! C’est le seul à exécuter du code applicatif

! Il attend la base… mais quelle est la requête ?

Identifier notre Thread

31 31 31

! Vérification de la configuration des traces

! Les requêtes de plus de 700ms sont tracées

! On obtient la requête et ses paramètres d’appel

Allons voir la DB

32 32 32

select sum(amount), …. from SaleOperation where groupId=1 and operationdate >= '2010-04-15 00:21:31.529' group by saleoperation.currency order by sum(saleoperation.amount) desc; ! Demandons au moteur du SGBD…

! Un index pourrait aider à mieux filtrer les lignes…

Pourquoi cette requête est lente ?

33 33

DÉMO 33

Exécution test unitaire

34 34 34

! Principes : la base de données est alimentées avec 2 sources !   Une (petite) partie des données est maitrisée

!   Généralement le jeux de données utilisés pour les tests d’intégration !   Cohérent avec les scripts d’injection (permet de faire des assertions)

!   Une (grosse) partie des données est générée aléatoirement

Remplissage des données : Benerator

xxx

xxx

Store

Stock



0,n

0,n

10,n0,n 1

10,n1

1,n

1

0,n

1

0,n

260

1'000

10'000

3'000'000

10'000'000

0

1'0001'000

256260

4 4

4

16

1

2

35 35 35

Configuration Benerator

36 36 36

! Temps de création de happystore è 1h20 ! 8 tables / 13 M de lignes ! (un thread sur MB avec VM)

! Temps de rechargement è 25 min

Temps de génération

38 38 38




Test de performance

unitaire



Test de charge



Test de rupture




39 39 39

Architecture

LOCAL SERVER APPLICATION SERVER

DATABASE SERVER


Gatling

PostgreSQL

JVM

Tomcat

40 40 40

Gatling - Recorder

41 41 41

Gatling – DSL Scala

URL + header http

page1

page2

Nb utilisateurs + durée

42 42 42

Montée en charge

nom

bre

d'ut

ilisat

eurs

duréeramp up durationdelay

20 min 2h

43 43 43

Exécution Gatling

44 44 44

Résultats Gatling

45 45 45

47 47 47

Premature optimization is the root of all evil - Donald Knuth

48 48 48

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 damn it!!!

49 49 49

Code

Mesure

Optimise Là où c’est

important

50 50

DÉMO 50

Visual VM

51 51 51

Architecture

TOOL SERVER APPLICATION SERVER

DATABASE SERVER

CI STACK

GRAPHITE STACK


Jenkins

Gatling Maven

Graphite

Collectd Carbon

Git

Collectd

Whisper PostgreSQL

JVM

Tomcat

52 52

DÉMO 52

Graphite & Metrics

53 53 53

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

54 54 54

55 55 55

Développement

Production

Architecture

Perf.

56 56 56

Développement Architecture

Perf.

1. Conception des tests

2. Automatisation des tests

3. Développement logiciel

4. Exécution auto- matique des tests

#1 #2 #3

57 57 57

Délai

PERFORMANCES

CATASTROPHIQUES

MEP À L’ARRACHE

Développement





#1 #2 #3

Architecture

Résultats

Perf.

Production

58 58 58





#1 #2 #3

Architecture

Tests de charge en continue

Développement Production

59 59 59

Intégrer les tests de performances au cycle de développement?

Hyperviseur

AppServer

Chef

DbServer

Chef

1

3

2

Créer environnement

Tir de performance

Destruction environnement

62 62

DÉMO 62

Automatisation des tests

63 63 63




Test de performance

unitaire



Test de charge



Test de rupture




64 64 64

Test de rupture

100 requ

êtes

par

sec

onde

s

nombre d'utilisateurs

requ

êtes

par

sec

onde

s


requ

êtes

par

sec

onde

s


65 65 65

Montée en charge

nom

bre

d'ut

ilisat

eurs


2h 0 min

66 66 66

Montée en charge et retour à la normal

nom

bre

d'ut

ilisat

eurs


67 67 67

Mesure Gatling

68 68 68

Mesures Graphite

69 69 69

Mesure GC

70 70 70




Test de performance

unitaire



Test de charge



Test de rupture




71 71 71

! Déterminer la capacité de l’application à fonctionner sur une période étendue

! Durant ce tests on va surveiller les dérives au cours du temps : !   Temps de réponse !   Consommation de ressource (espace disk, CPU, mémoire, etc.) !   Libération des ressources (connexions, file, etc.) !   Mémoire

Objectif

72 72 72

Montée en charge

nom

bre

d'ut

ilisat

eurs


20 min 24h

73 73

DÉMO 73

Test d’endurance

74 74 74

! Analyse des logs GC avec HPJMeter (ou Censum) !   -Xloggc:gc.log -XX:+PrintTenuringDistribution -XX:+PrintGCDetails

Memory Leak [1/3]

75 75 75

! Heapdump puis Eclipse Memory Analyzer (statique) !   Rapport sur les suspects

Memory Leak [2/3]

76 76 76

! Visual VM (dynamique) !   On cherche les objets vivants avec un grand nombre de génération ! Jdk 8+ pour les JVM remote

Memory Leak [3/3]

77 77 77

Préparer les jeux de données Benerator Exécuter une mesure unitaire Chrome developer tools Identifier un problème d’index jstack, explain 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 Identifier une fuite mémoire VisualVM, EMA, HPJMeter Tuning système Bonnie++

Résumé de la session

78 78 78

! Tunning Système !   Exemple Bonnie++

Pour aller plus loin

80 80 80

! La conférence originale à Devoxx FR 2014 : https://parleys.com/play/536749d1e4b04bb59f502709

! 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/

Liens utiles

81 81 81

!  Remerciement à Henri Tremblay, Marc Bojoly, Mickaël Robert & Ludovic Piot

82 82 82

+Jean Philippe Briend @jpbriend [email protected]

+Philippe Kernevez @pkernevez [email protected]

université de la performance

Software

test application

test de charge objectif

performance unitaire

lapplication ex

mesure de performance

global tests de charge

charge constante

lapplication jusqu