Le document traite de la performance des systèmes informatiques, abordant des concepts tels que la dimensionnement des ressources, les problèmes de concurrence, et la gestion des performances sous charge. Il souligne l'importance de la collaboration entre les équipes, des tests de charge, et des indicateurs pour évaluer l'efficacité des applications. Des conseils pratiques sur la prévention des problèmes de performance et l'optimisation des ressources sont également fournis.

1. Diagnostic performance
Claude Falguière
JUG Toulouse
le 7 décembre 2011
JUG Bordeaux
le 8 décembre 2011
1

2. Copyright notice
http://creativecommons.org/licenses/by/3.0/
Vous êtes libre de :
Reproduire, distribuer et communiquer cette création au public
Modifier cette création
Selon les conditions suivantes :
Paternité. Vous devez citer le nom de l'auteur original de la manière indiquée par
l'auteur de l'oeuvre ou le titulaire des droits qui vous confère cette autorisation (mais
pas d'une manière qui suggérerait qu'ils vous soutiennent ou approuvent votre
utilisation de l'oeuvre).
Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des
auteurs.
2

3. Claude Falguière
Architecte Technique
Co-fondatrice
@cfalguiere
Crew member
3

4. 4

5. Faux ami 1
La dream Team
X est performant
Y est performant
Z est performant
=>
Mon système est performant
5

6. Sprint ou
marathon ?
6

7. Vitesse ou Bus RATP
charge ?
Modèle Simlocker
Modèle Fiat 500
7

8. Faux ami 2
C’est du bon sens !
8

9. User expe!ence
9

10. Subjectif
Complexité supposée
Ordre d'affichage
Stabilité
10

11. Logique
mais souvent Nombreux composants
Interactions complexes
Contre-intuitif Caches
Mécanismes correctifs
11

12. Faux ami 3
Avec le cloud fini
les problèmes
12

13. Essentiellement du scale out
Dʼautres problèmes liés à la mutualisation (latence I/O)
Coût de la montée en charge
13

14. Jusque là
tout
va bien
14

15. Une application
ne rend le
service prévu
aux utilisateurs
que si elle est
déployée
15

16. DEV
OPS
16

17. 17

18. Si vous avez un
marteau
tout ressemble à un
clou
18

19. Donʼt shoot in the dark
19

20. travailler ensemble ?
20

21. 21

22. 22

23. http://parisdevops.fr/
http://devops.fr
Des User Groups
Lille
Paris
Lyon
Qui sera le prochain ?
23

24. Partager
24

25. ?
n !
Klo
Zzzz
zzzzz
z
25

26. A la pêche aux infos
Dis, je comprend
pas pourquoi ça
marche pas
Tu peux revéri er
toute la procédure
d’installation ?
Non
26

27. Explicitez vos
hypothèses
et votre démarche
27

28. La
Scène
de
Crime
28

29. 29

30. 30

31. 31

32. 32

33. Investigations
33

34. Vital
Risqué
Que fait ce système ?
Fréquent
34

35. Comment ça marche ?
35

36. 36

37. 37

38. 38

39. 39

40. 40

41. Ce que vous mesurez soit servir à
- bâtir des hypothèses
- (in)valider des hypothèses
41

42. Patterns
42

43. Comportement sous stress
Isolé Groupe Foule
Conflits Saturation
43

44. Capacité Ressources limitées + Charge
Saturation
Attente Rejet
44

45. Concurrence
Accès partagé à la même ressource
Problème de cohabitation
Attente Mélange
45

46. Répétition Efficacité
Volume
Attente d’éléments externes
46

47. 47

48. Utilisateurs actifs CPU
Bande passante réseau Mémoire
48

49. 11 mois plus tard ...
Utilisateurs actifs CPU
Bande passante réseau Mémoire
49

50. Les limites physiques
Memory bound :
ressource non partageable
→ erreur quand plus de ressources
CPU bound :
ressource en time sharing
→ partage excessif, lenteur
Network bound :
ressource en time sharing
→ idem + retry et écroulement
50

51. Les Limites configurables
Configuration mémoire de la JVM (-Xmx)
Tailles limites de pool
Tailles limites de caches
Nombre dʼinstances, de connexions ...
51

52. Dimensionner
les pools
52

53. Les tailles de pool
Taille du
pool
53

54. Les tailles de pool
Mémoire Taille du
pool
CPU
Réseau
54

55. Les tailles de pool
File
d’attente
Taille du
pool
55

56. Y’a Ka sources Wikipedia
théorie des files d’attente
files d’attentes markoviennes (M/M/S)
loi de Little
■ λ = fréquence moyenne d'arrivées (loi de Poisson)
■ temps moyen de service
■ trafic offert (nombre moyen d'arrivées pendant le temps moyen de service)
■ S nombre de serveurs
Nombre moyen de clients dans le système (<N>) Probabilité d'attente (Pa) Temps moyen de séjour dans le système (τ)
56

57. réseau de files d’attentes
57

58. Approche pragmatique
Estimation globale à partir de tests standardisés
(SPEC http://www.spec.org/)
Calibrage par des tests en charge
58

59. 59

60. Waiting for
I/O
Augmentation des
tailles de pools tant
que le nombre de ( )
runnable n’excède pas ( ) attend
le nombre de CPU ( )
Runnable
(vmstat) (mais de
pas de CPU
dispo)
60

61. Influence
Influence de ( )
des jeux
la vitesse des ( ) attend
de
utilisateurs ( )
données
Influence des
scénarios joués
61

62. Tout ce qui rentre doit
ressortir ... en moyenne
File d’attente =
temporisation des pics
90
62

63. Cohérence
plutôt que
Rock StarS
63

64. L’entonnoir
64

65. Dimensionner
la mémoire
65

66. GC, GC
Règle usuelle :
temps de GC < 5% uptime process
Memory profiler
ou
-verbose:gc + GCViewer
66

67. Les tailles Mémoire
4Go
-Xmx800m
67

68. Les tailles Mémoire
OutOfMemory : Not enough swap space left
4Go
quota
1Go
-Xmx800m
1,2 Go
68

69. douter
ne pas prendre tous les
messages au pied de la lettre
69

70. Les Quotas
Mutualisation de ressources,
Réserver des ressources au système,
Priorisation de service,
Facturation
ulimit,
hyperviseurs,
shaping réseau,
les licences ...
70

71. 71

72. 72

73. 1 CPU
73

74. La limite logicielle est
préférable à l’écroulement
( )( )( )
( )( )( )
( )( )( )
( )( )( )
( )( )( )
Taille du Tout le
pool trop monde attend
ambitieuse
74

75. 75

76. Taille du
pool
inefficace
76

77. 77

78. Ressources limitées
+
Ressources non rendues
+
Charge
Saturation
78

79. Mémoire
Connexion non rendue au pool
Thread bloqué
79

80. Les pseudos fuites
Evaluer l'utilité des caches :
thrashing,
jamais relus
Utiliser un vrai cache :
gestion de la durée de rétention,
recyclage,
utilisation de weak/soft reference
80

81. Récap
Capacité
81

82. Signes
Les indicateurs se
dégradent
progressivement
Se produit
sous charge
Souvent écroulement
Affecte après un pic de charge
l’ensemble
Pas de saturation de
des use cases limites matérielles
Se produit avec le temps
même à faible charge
82

83. Prévention
Capacity Planning
Tests en charge
Tests de vieillissement
83

84. 84

85. Ressource à partager
Verrou
Lock
synchronized
Transactionnel
(Java)
(DB)
85

86. Très long si
attente mutuelle
(Deadlock / Livelock)
ou
famine sur le premier
86

87. Situations propices
variables de classes
variables d’application (compteurs applicatifs)
collections auto-synchronized (Vector, Hashtable)
87

88. Java
→ Thread Dump + outil d'analyse
(MAT, JCA, HealthCenter,
Samourai)
Evaluer les portées des synchronized
BD
→ voir les outils de DBA
88

89. 89

90. 90

91. 91

92. Ressource à partager
Verrou
Corruption de
données
partagées Comportement
instable
92

93. Utilisation par plusieurs
threads de variables de
classe non multi-thread safe
(formatters)
93

94. Situations propices
- Optimisations sauvage des synchronized pour régler
des problèmes de performance
- Caches et compteurs applicatifs mal gérés
- Formatters
94

95. Proposer des alternatives propres
Concurrent Collections
librairie «parallèles» type Gpars
Immutabilité
Thread Local, Volatile
Synchronized à portée réduite
95

96. Récap
Concurrence
96

97. Signes
- Très faible
consommation de
ressources
- Temps très longs
A faible
(time-outs)
charge
Affecte plus
certains use case
- Incohérence
- Instabilité
97

98. Prévention
Provoquer le conflit par un tests
à 2 utilisateurs simultanés
1 des 2 est deux fois plus long
1 des 2 est en erreur
... si vous avez de la chance
Très difficile à identifier
98

99. 99

100. Signes
Préciser le scénario
Long même en unitaire - donnée en cause
- volumes / répétition
Localisé sur un use case
- scénario alternatif
Variations pour un
même use case Volume
100

101. Dresser
le bilan
101

102. Temps de Temps de
rendering réponse serveur
102

103. 103

104. 104

105. 105

106. 106

107. 107

108. Plusieurs sources
Latences
108

109. Parler
Faire
Les
Chiffres
109

110. Série Chronologique
Et sa distribution
110

111. Quelques
mauvais
temps isolés
Temps très
variables
Bimodale !? ...
111

112. Que dis cette bimodale ?
112

113. Que dis cette bimodale ?
Comportement
différent selon les Plusieurs cas sous
instances le même use case
mesuré
Lock
Cache
113

114. 114

115. Appels externes
- Limiter le temps d’attente et les
traiter les non-réponse en
erreur
- Logguer les temps anormaux aux
extrémités du système
- utiliser des appels asynchrones
115

116. Répétition
- log, requêtes JDBC dans des boucles
- requêtes involontaires (cascade, refresh)
- répétition induite par le volume de données
bon candidat pour la parallélisation
techniques de Map Reduce
- problèmes d’algorithme
116

117. Complexité algorithmique
http://fr.wikipedia.org/wiki/Th%C3%A9orie_de_la_complexit%C3%A9_des_algorithmes
117

118. Structures de données
- Informations additionnelles
(index, tri)
- Organisation de l’information pour
faciliter les parcours
- Structures spécialisées
(tables de hachage, arbres équilibrés)
118

119. Volume
Fractionnement
Facteurs de blocage
- Ecritures fichiers bufferisées
- JDBC Fetch size
Redimensionnement de
structures de données
non mutables
119

120. Conclusion .
120

121. Priorités
Fonctions
Robustesse
Stabilité
Rapidité
121

122. 122

123. Anticiper
≠ planifier
123

124. Quelques ressources
http://javaperformancetuning.com/
http://highscalability.com/
http://velocityconf.com/velocity20xx
124

125. Merci pour votre attention
Questions ?
@cfalguiere
125

126. 126