Définir l'Analyse de Performance
Il y a beaucoup de définitions de "l'analyse de performance", mais selon mon opinion une des plus utiles est :
Une approche pilotée par la mesure pour comprendre comment une application se comporte sous la charge.
Les mérites de cette définition sont que cela porte l'attention sur la mesure comme clé du processus entier, et par simple extension porte aussi l'attention sur les statistiques et l'analyse de données en tant qu'activités probablement importantes pour l'ingénieur performance.
Allons plus loin : cela aide à positionner l'analyse de performance comme une activité fondamentale et empirique, qui ressemble à la science expérimentale avec les entrées et sorties.
Ces sorties peuvent alors être revues sous forme de questions à réponses quantitatives - telles que :
Avec 10x plus de clients, est-ce que le système aura suffisamment de mémoire pour tenir ? Quel temps de réponse moyen les utilisateurs constatent-ils sur l'application ? A quoi ressemble le reste de cette distribution ? Comment cela se situe par rapport à nos concurrents ?
Avec cette formulation, la performance telle que exprimée par ces bonnes pratiques est plus une science qu'un art ; une activité qui est fondamentalement quantitative et qui a une relation directe avec les activités métier.
Cependant, malgré ces attributs, la performance s'est souvent langui dans un état où même les bonnes pratiques bien connues sont à la traîne derrière la réalité des praticiens.
Il y a un certain nombre de modèles différents qui peuvent expliquer cela, mais une intéressante possibilité est fournie par Carey Flichel dans le superbe article "Pourquoi les développeurs continuent de faire des mauvais choix technologiques".
Dans l'article, Carey dénonce spécifiquement cinq raisons principales qui font faire aux développeurs de mauvais choix :
- l'Ennui
- le Remplissage de CV
- la Pression des Pairs
- le Manque de Compréhension du Système Existant
- le Problème Incompris / Inexistant
Dans cet article, nous présentons certains des anti-patrons (ou antipatterns) d'analyse de performance les plus communs en entreprise, et nous essayons de les exprimer sous la forme de leur causes basiques telles que énumérées par Carey. Les exemples spécifiques qui conduisirent à la distillation qui suit sont tirés de l'écosystème Java, mais des remarques similaires s'appliquent à beaucoup d'autres types de systèmes d'entreprise.
Chaque cause basique correspond à un biais cognitif. Par exemple, l'Ennui et le Remplissage de CV proviennent tout deux d'un désir d'échapper à la technologie existante qu'un développeur utilise dans son travail quotidien, et de leur désir pour des lendemains meilleurs.
Les antipatterns sont présentés ci-dessous, dans un format et un style qui devraient rappeler le Gang of Four, ainsi bien sûr que le format d'antipattern dont Brown et al. fûrent les pionniers.
Catalogue d'AntiPatterns
Distrait par Tout Ce Qui Brille
Description
La techno la plus récente ou la plus cool est souvent la première cible des optimisations.
Commentaire d'Illustration
On est en train d'essuyer les plâtres - il faut aller au bout des choses avec ce problème.
Réalité
- Il s'agit juste d'un tir en aveugle
- Les développeurs ne comprennent pas vraiment la nouvelle technologie
Causes racines
- Ennui
- Remplissage de CV
Discussion
Cet antipattern est le plus souvent vu dans des équipes jeunes. Bien décidées à faire leurs preuves, ou à éviter de se retrouver menottées à ce qu'elles voient comme des systèmes legacy, elles sont souvent partisantes de technologies plus récentes, plus "sympas" - ce qui pourrait par coïncidence être exactement le type de technologie justifiant une légère hausse de salaire au travers d'un nouveau rôle.
Ainsi, la conclusion logique subconsciente à tout problème de performance est de d'abord regarder les nouvelles technologies - après tout, elles ne sont pas bien comprises, donc un nouveau regard devrait aider, n'est-ce pas ?
Résolutions
- Mesurer pour déterminer la localisation réelle du goulot d'étranglement
- S'assurer d'avoir des logs adéquats autour des nouveaux composants
Distrait par la Simplicité
Description
Les parties les plus simples du système sont ciblées en premier.
Commentaire d'Illustration
Attaquons-nous à ce problème en commençant par les parties qu'on comprend bien.
Réalité
- Les développeurs comprennent comment régler (seulement ?) cette partie du système
Causes racines
- Manque de Compréhension du Système Existant
Discussion
Le double du "Distrait par Tout Ce Qui Brille" ; cet antipattern est souvent vu dans une équipe plus mature, mieux établie, qui pourrait être plus axée sur un rôle de maintenance/"entretien du feu". Si leur application a récemment été inclue ou associée à de nouvelles technologies, l'équipe pourrait se sentir intimidée ou ne pas vouloir se frotter aux nouveaux systèmes.
Dans ces circonstances, les développeurs peuvent se sentir plus confortables en n'analysant seulement ces parties du système qui sont familières, espérant qu'ils arriveront à produire le résultat escompté sans sortir de leur zone de confort.
Un point d'intérêt particulier est que ces deux premiers antipatterns sont induits par une réaction face à l'inconnu ; dans "Distrait par Tout Ce Qui Brille", cela se manifeste par un désir du développeur (ou de l'équipe) d'apprendre plus et de gagner un avantage - essentiellement un mouvement offensif. Par contraste, "Distrait par la Simplicité" est une réaction défensive - jouer sur un terrain familier plutôt que d'affronter une nouvelle technologie potentiellement menaçante.
Résolutions
- Mesurer pour déterminer la localisation réelle du goulot d'étranglement
- Demander de l'aide aux experts du domaine si le problème se situe dans un composant qui n'est pas familier
L'UAT sur mon Poste
Description
L'environnement d'UAT (User Acceptance Testing ou Test d'Acceptance Utilisateurs) diffère significativement de la PROD.
Commentaire d'Illustration
Un environnement complet d'UAT coûterait bien trop cher.
Réalité
- Les pannes causées par une différence entre environnements sont quasi toujours plus coûteuses que quelques serveurs de plus
Causes racines
- Problème Incompris / Inexistant
Discussion
L'UAT sur mon Poste trouve sa source dans un genre différent de biais cognitif par rapport à celui vu précédemment. Ce biais induit que faire n'importe quelle sorte d'UAT est forcément mieux que ne pas en faire du tout. Malheureusement, cet espoir ne tient fondamentalement pas compte de la nature complexe des environnements d'entreprise. Pour que tout type d'extrapolation significative soit possible, l'environnement d'UAT doit être semblable à la production.
Dans les environnements modernes et adaptatifs, le sous-système d'exécution tirera le meilleur parti de toutes les ressources disponibles. Si celles-ci diffèrent radicalement du déploiement cible, ils prendront des décisions d'exécution différentes - rendant notre extrapolation pleine d'espoir inutile au mieux.
Résolutions
- Traquer le coût des pannes et le coût d'opportunité lié à la perte de clients
- Investir dans un environnement d'UAT qui soit identique à la PROD
- Dans la plupart des cas, le coût du premier dépasse largement celui du second
Avoir des Données comparables à la PROD, c'est Difficile
Description
Les données en UAT ne ressemblent pas du tout à celles en PROD
Commentaire d'Illustration
C'est trop difficile de garder l'UAT et la PROD en synchro
Réalité
- Les données d'UAT doivent ressembler à celles de PROD pour des résultats précis
Causes racines
- Manque de Compréhension du Système Existant
Discussion
Cet antipattern tombe aussi dans le piège du "quelque chose est forcément mieux que rien du tout". L'idée est que tester sur des données même dépassées et non-représentatives est mieux que de ne pas tester du tout.
Comme précédemment, c'est une ligne de raisonnement extrêmement dangereuse. Même si tester sur quelque chose (même si ça ne ressemble en rien à la donnée de PROD) à l'échelle peut révéler des failles et omissions lors des tests systèmes, cela donne une fausse impression de sécurité.
Quand le système est mis en ligne, et les motifs d'usage échouent à se conformer aux normes attendues qui ont été inspirées par les données d'UAT, les équipes de développement et opérationnelles pourraient bien découvrir qu'elles ont été trop complaisantes à cause de la chaleur réconfortante de l'UAT, et ne sont en fait pas préparées pour la pure terreur pouvant rapidement faire suite à une mise en production à grande échelle.
Résolutions
- Consulter des experts du domaine de la donnée et investir dans un processus pour migrer la donnée de PROD dans l'UAT
- Se sur-préparer pour les MEP à grande échelle
- Quand c'est possible, avoir des équipes ou des outils "au pire des cas" (par exemple Chaos Monkey (en anglais)
Astuces de Performance (ou le Réglage Folklorique)
Description
Des changements de code et de paramétrage sont appliqués en aveugle.
Commentaire d'Illustration
J'ai trouvé ces supers astuces sur Stack Overflow. Ca change tout.
Réalité
- Les développeurs ne comprennent pas le contexte ou la base de l'astuce de performance et l'impact réel est inconnu
Causes racines
- Manque de Compréhension du Système Existant
- Pression des Pairs
Discussion
Une astuce de performance est un contournement pour un problème connu - en essence, une solution qui se cherche un problème. Elles ont une date de péremption et généralement vieillissent mal - quelqu'un trouvera une solution qui rendra l'astuce inutile (au mieux) dans une future livraison de la plate-forme logicielle.
Une source d'avis sur la performance qui est généralement particulièrement mauvaise serait les manuels d'administration. Ils contiennent des conseils génériques dépourvus de contexte - conseils et "configurations recommandées" qui ont souvent été inclus à la demande des avocats, comme ligne de défense additionnelle si l'éditeur est attaqué en justice.
La performance en Java survient dans un contexte spécifique, avec un large nombre de facteurs y contribuant. Si nous nous détachons de ce contexte, il devient presque impossible de raisonner sur ce qui reste, à cause de la complexité de l'environnement d'exécution.
Résolutions
- Appliquer seulement des techniques bien testées et bien comprises, qui affectent directement les aspects les plus importants d'un système
la Tête de Turc
Description
Certains composants sont toujours identifiés comme sources du problème.
Commentaire d'Illustration
C'est toujours JMS / Hibernate / AUTRE_LIB.
Réalité
- L'analyse conduisant à cette conclusion était insuffisante
Causes racines
- Pression des Pairs
- Problème Incompris / Inexistant
Discussion
Cet antipattern est souvent présent chez le management ou le métier, car dans beaucoup de cas, ils n'ont pas une compréhension complète de la pile technique et procèdent donc par "reconnaissance de forme", ou bien ont des biais cognitifs qu'ils ne reconnaissent pas. Cependant, les technologistes sont loin d'être immunisés à cet antipattern.
Résolutions
- Résister à la pression de se précipiter sur les conclusions
- Réaliser l'analyse normalement
- Communiquer les résultats de l'analyse à toutes les parties intéressées (de manière à essayer d'encourager une image des causes de problèmes plus précise)
Jouer avec les Interrupteurs
Description
L'équipe devient obsédée par les arguments de paramétrage de la JVM.
Commentaire d'Illustration
Si je changeais juste ces paramètres, nous obtiendrions de meilleures performances.
Réalité
- L'équipe ne comprend pas l'impact des changements
Causes racines
- Manque de Compréhension du Système Existant
- Problème Incompris / Inexistant
Discussion
La JVM possède littéralement des centaines de leviers de paramétrage - cela permet d'obtenir un runtime hautement configurable, mais donne aussi lieu à une forte tentation d'utiliser toute cette configurabilité. C'est généralement une erreur - les valeurs par défaut et les capacités d'auto-gestion sont généralement suffisantes. Certains des paramètres se combinent aussi entre eux de manière imprévue - ce qui rend les changements en aveugle d'autant plus dangereux.
Résolutions
Avant de mettre en place des changements de paramètres :
- Mesurer en PROD
- Changer un paramètre à la fois en UAT
- Tester le changement en UAT
- Re-tester en UAT
- Demander à quelqu'un de re-vérifier votre raisonnement
Microbenchmarking
Description
L'effort de réglage est concentré sur des aspects très bas-niveau du système.
Commentaire d'Illustration
Si nous pouvions juste diminuer le délai de dispatch de méthodes...
Réalité
L'impact de micro-changements au niveau du système global est hautement inconnu.
Causes racines
- Manque de Compréhension du Système Existant
- Problème Incompris / Inexistant
- Remplissage de CV
- Pression des Pairs
Discussion
Le réglage fin de performance est une activité statistique, qui se repose sur un contexte d'exécution hautement spécifique. Cela implique que les systèmes plus gros sont habituellement plus faciles à benchmarker que les plus petits - parce qu'avec les plus gros systèmes, la loi des grands nombres tourne en la faveur de l'ingénieur, aidant à corriger les effets de la plate-forme qui distordent les événements individuels.
Par contraste, plus on essaye de se concentrer sur un aspect individuel du système, plus nous devons travailler dur afin de nous détacher de la pelote de sous-systèmes séparés (par exemple le threading, le GC, la planification, la compilation "Juste-à-Temps" JIT, etc...) dans l'environnement complexe qui constitue la plate-forme (en tout cas dans le cas de Java et C#). C'est extrêmement difficile à faire, et la manipulation de statistiques est sensible et pas souvent un jeu de compétences acquis au cours du temps par les ingénieurs. Par conséquent, il devient très facile de produire des chiffres qui ne représentent pas avec précision le comportement de l'aspect du système que l'ingénieur croyait benchmarker.
Cela a une tendance infortunée à se combiner avec les biais humains à voir des motifs partout, même quand aucun n'existe. Ensemble, ces effets nous mènent au spectacle d'un ingénieur de la performance qui a été profondément séduit par de mauvaises statistiques ou un mauvais contrôle - un ingénieur argumentant passionnément en faveur d'un benchmark de performance ou d'un effet que ses pairs ne sont tout simplement pas capables de reproduire.
Résolutions
- Ne pas faire de microbenchmark sauf si vous savez que vous avez un cas d'utilisation connu pour y être adapté ; et alors le faire publiquement, et accompagné par vos pairs
- Etre préparé à avoir tort, beaucoup, et challenger sa réflexion de manière répétée
Conclusion
Pourquoi le réglage de performance a-t'il acquis ces antipatterns ? Qu'est-ce qui, dans le processus de réglage, encourage les biais cognitifs qui mènent à de telles conclusions incorrectes ?
La clé de ces questions est de comprendre que l'ingénierie logicielle est fondamentalement différente des autres disciplines d'ingénieurs. Dans un large spectre de systèmes d'ingénierie mécanique, les propriétés physiques de petits composants sont bien connues et les effets de composition mènent seulement à de petites quantités (souvent bien étudiées) de comportements émergents.
Le logiciel est différent. Les systèmes que nous construisons sont bien plus élaborés que ceux typiquement trouvés ailleurs dans les efforts humains. C'est à la fois parce que nous travaillons avec des pièces de base très simples et aussi parce que nous avons construit des outils qui nous permettent de travailler avec des quantités énormes de pièces de base. Malheureusement (ou de manière fascinante, selon votre point de vue), alors que le logiciel est devenu de plus en plus complexe, nous avons découvert qu'il avait une nature hautement émergente. Cela signifie que des phénomènes inattendus se sont manifestés au fur et à mesure que notre complexité augmentait - et, comme nous en avons discuté dans cet article, tous ne sont pas positifs.
Remerciements
Un merci spécial à Martijn Verburg, Kirk Pepperdine, Trisha Gee et James Gough (et les autres) pour avoir élucidé (et dans plusieurs cas nommé) ces antipatterns pour moi.
A propos de l'Auteur
Ben Evans est CEO de jClarity, une startup d'analyse de la performance de Java/la JVM. Dans son temps libre, il compte parmi les leaders de la communauté Java Londonienne et tient un siège au Commité Exécutif du Java Community Process. Ses précédents projets incluent le test de la performance de l'Offre Publique Initiale de Google, de systèmes financiers de trading, la réalisation de sites web décorés pour certains des plus grands films des années 90, parmi d'autres.