Dans le monde de la livraison d'application, le tuning de performance semble échapper au courant dominant. InfoQ a eu l'occasion de discuter avec cinq personnalités de l'analyse de performance à propos des causes et de ce qui peut être fait pour y remédier. Le résultat a été un débat plutôt enflammé.
Les membres du panel virtuel :
- Ben Evans est CEO de jClarity, une startup qui propose des outils pour aider les développeurs et ops à analyser et améliorer les performances. Il est aussi Oracle Java Champion et auteur à succès.
- Charlie Hunt est Architecte Performance pour Salesforce.com et auteur principal du livre "Java Performance".
- Kirk Pepperdine est Consultant sur le tuning de performance de renommée mondiale, formateur, Oracle Java Champion, et contributeur du livre "97 things every programmer should know".
- Martin Thompson est spécialiste des hautes performances et basses latences, avec plus de deux décennies d'expérience sur de grands systèmes transactionnels et big data.
- Monica Beckwith est Oracle performance lead pour le Garbage First Garbage Collector.
InfoQ : La plupart des sociétés tendent à négliger les tests de performance et le tuning. Peut être pouvez-vous partager vos expériences sur comment surmonter ces difficultés. Quelles pratiques, outils et ressources, une société devrait utiliser pour rendre routinier le tuning de performance ?
Martin : "Tendent à négliger" est un euphémisme ! La plupart semblent uniquement s'empresser de livrer le produit et ne pensent pas à la qualité ni à aucun besoin non fonctionnel comme la performance, la disponibilité, la sécurité, etc.
InfoQ : Je suis d'accord, j'ai récemment fait passer des entretiens pour des candidats pour des postes senior en Java et le nombre de ces développeurs expérimentés qui n'ont jamais utilisé un profiler et qui ne connaissent rien en tuning de performance ou GC est incroyable. Est-ce une conséquence ou une difficulté inhérente ? A moins que la réflexion sur les performances ne soit qu'après coup ? Que peuvent faire les sociétés pour corriger ce problème ?
Martin : La vraie surprise pour moi en recommençant le consulting est le peu de connaissances que les gens ont sur les tests de performance et le tuning même, quand la performance est un besoin clé pour leur domaine d'activité.
Ben : Je pense que certains des problèmes que vous mentionnez sont connectés et sont liés à la manière dont nous développons nos ingénieurs performance. J'ai vu cette citation récemment, que je pense pertinente :
"L'entrainement apprend à une personne comment remplir une certaine tâche plus efficacement et de façon plus fiable. L'enseignement ouvre et enrichit son esprit".
Pour gérer des problèmes de performance, les deux aspects sont nécessaires. Nous devons apprendre aux étudiants l'importance des données empiriques, des statistiques et de la reproductibilité des tests de performance et du tuning (qui est un aspect de l'entrainement). Néanmoins, nous devons aussi leur faire comprendre comment appliquer leur propre expérience de toute leur pile applicative sur le problème de performance (ce qui est plutôt un aspect de l'enseignement).
Non seulement ça, mais nous devons les éloigner de l'approche "trucs et astuces" de la performance (qui est plus simple à enseigner, puisque c'est de l'entrainement plutôt que de l'apprentissage).
Enfin, quand confronté à de l'enseignement ou à de l'entrainement, l'étudiant doit utiliser régulièrement le matériel et les nouvelles compétences, qui autrement vont s'atrophier à nouveau. Assister à un cours sur les performances qui n'est pas utilisé couramment dans les 12 mois qui suivent est inutile.
Kirk : Il y a un certain temps, j'ai assisté à une conférence donnée par Eric Smart. Il mettait en évidence les erreurs classiques qu'ils avaient faites. Premièrement, le focus était mis sur les fonctionnalités, les fonctionnalités et encore plus de fonctionnalités. Ils étaient un groupe de personnes intelligentes et les problèmes de performance seraient réglés en temps et en heure. Le problème était que, quand la performance a finalement été requise, chaque jour ils se rapprochaient de l'objectif, juste un peu plus de temps et ça serait bon, un jour de plus, une semaine de plus, ensuite un mois, deux, trois puis quatre. A cet instant, ils se sont arrêtés pour se demander "ok, qu'est ce qui se passe ?". Ils ont réalisé qu'en ne faisant pas de la performance une part de leur routine quotidienne, ils ont ignoré les problèmes qui étaient invisibles à petite échelle. C'était précisément contre ces problèmes qu'ils luttaient, au point qu'ils avaient presque fait échouer le projet, et par extension la société.
Cette histoire a une fin heureuse car ils ont pu transformer une mort lente en un succès. Mais il leur a fallu prendre conscience que le mode de développement traditionnel ne les avait pas si bien servi.
Monica : Il y a aussi cet autre aspect où une société a quelqu'un avec le titre "d'ingénieur performance" qui collecte des données (brutes, logs ou profiles) pour comparaison, mais qui est incapable de prendre le temps (à cause d'un manque de connaissances ou d'engagement de la société) d'analyser et d'explorer en profondeur les données pour détecter des problèmes de performance subreptices. A l'autre extrémité du spectre, il y a un ingénieur performance qui n'est pas directement investi dans le produit car il ou elle travaille dans un groupe déconnecté, et suggère toujours des changements majeurs qui deviennent trop coûteux pour être réalisés. Je pense que le problème dans de tels cas peut être résumé à un manque de compréhension ou de définition précise d'un plan de performance.
J'ai pu observer au cours de ma carrière un engagement de sociétés, mais je pense que certaines doivent travailler sur le problème des groupes déconnectés, et quelques "ingénieurs performance" doivent encore acquérir des connaissances. Cela dit, j'ai aussi travaillé avec de nombreux développeurs qui comprenaient les performances. C'est comme toucher le jackpot pour une société.
Le tuning de performance est un art. Certains praticiens peuvent être plus doués que d'autres, mais celui qui remplit le rôle doit pratiquer et perfectionner cet art. Et ensuite il nous incombe, nous autres ingénieurs performance, de transmettre nos connaissances aux autres. Cela peut être accompli avec des forums ouverts et des conférences, et en conseillant directement les équipes.
Kirk : Je pense que cela dépend de ce que vous entendez par tuning. Essayer de comprendre pourquoi les performances de votre application ne sont pas aussi bonnes qu'espérées est un problème de diagnostique. Savoir quoi faire une fois que vous avez trouvé le problème peut entrer dans deux catégories :
- Nous avons déjà vu cela et la solution est connue
- Nous devons trouver une façon novatrice d'obtenir plus du matériel
La solution ne dépend donc pas uniquement des capacités de diagnostique, elle dépend aussi de ce qui doit être fait pour améliorer les performances. Selon mon expérience, la plupart des problèmes de performance une fois détectés sont simples à résoudre. Je pense que les plus grandes difficultés sont dans le diagnostic.
Quand j'ai entendu Martin poser la question "Combien de personnes ont appris à utiliser un profiler ?" à Devoxx Londres, ma première pensée a été "Quelle question simple mais brillante !" Question que je n'avais jamais pensé à poser car je connais la réponse. Mais elle a quand même besoin d'être posée pour montrer l'évidence. Les profilers devraient être un outil important dans notre arsenal de diagnostique mais je ne connais pas une seule école ou institution qui couvre le sujet. J'ai été contacté par des professeurs de quelques universités qui se demandaient comment le sujet du tuning pourrait être enseigné mais ça n'est pas allé plus loin.
Pour en revenir à cette idée que le tuning est difficile, je pense qu'une des raisons est que c'est une activité de diagnostique et en tant que telle est fondamentalement différente du développement. De part sa nature, c'est une investigation, et par sa nature il faut obtenir des mesures. Non pas n'importe quelles mesures, mais la bonne mesure, qui expose le problème. Et c'est là que réside le problème : comment quelqu'un est censé obtenir la bonne mesure si tout ce qu'il sait faire est utiliser un profiler dans un IDE. Sans la bonne mesure, vous restez avec vos intuitions et suppositions. Le problème avec l'intuition, c'est qu'on ne peut pas imaginer toutes les interactions qui surviennent quand le logiciel rencontre le matériel et les vrais utilisateurs. C'est ce qui a mené au mantra "Mesurez, ne supposez pas™" que Jack Shirazi et moi-même avons inventé. C'est aussi ce qui a mené au Performance Diagnostic Model™ que j'enseigne dans mon cours. PDM m'a permis d'aider des développeurs à repackager ce qu'ils savaient déjà en quelque chose qui peut amenuiser les difficultés dans le diagnostic des problèmes de performance.
Même si PDM aide, il a seulement légèrement amélioré le taux de succès dans mon exercice d'exemple. C'est parce que le diagnostic nécessite une autre compétence qui est la capacité à élever la pensée hors des détails pour comprendre la globalité. Le diagnostic, comme toute forme de résolution de problème, nécessite que vous alliez dans les détails et il devient parfois difficile de se recentrer pour acquérir une compréhension plus large. Comment corriger cela est au dessus de mon niveau de rémunération. Mais c'est un problème qui a un effet sur la capacité à suivre un processus de diagnostique.
Martin : Nous avons observé que "la plupart ne mesurent pas ou n'utilisent pas de profiler". Mais j'ai observé un phénomène encore plus intéressant. Pour les membres des équipes qui font du profiling et qui collectent les métriques du système, quand ils regardent les données, elles semblent n'avoir aucun sens pour eux. Je vais souvent chez des clients et ils me disent qu'ils ont des problèmes de performance. Je leur demande s'ils ont profilé l'application de plusieurs manières. Dans mon domaine, ils ont souvent des licences de profilers, les logs GC activés, System Activity Report, etc. Je suis alors surpris quand ils me montrent les données. La réponse me saute aux yeux et ils ne semblent pas capables de la voir. Il m'a fallu du temps pour réaliser que ce n'est pas parce qu'ils ne sont pas intelligents. Ils ne savent simplement pas comment interpréter les données car ils n'ont pas affûté cette compétence. C'est similaire à ce que nous trouvons avec un debuggueur, quand vos pratiques de travail vous en font utiliser un tous les jours, il devient comme une seconde nature. A l'exception de ça, c'est presque un handicap.
Charlie : Je suis d'accord avec Monica sur le fait que la définition "d'ingénieur performance" semble varier selon les sociétés et l'interlocuteur que vous y avez. Pour certaines sociétés, un ingénieur performance est quelqu'un qui fait des tests de performance, qui va lancer des charges de test de performance sur le produit en cours de développement et rapporter les résultats, améliorations, régressions, ou non concluant. Dans d'autres contextes, les ingénieurs performance vont plus loin et font des analyses pour identifier les sources d'amélioration ou régression. Il y en a encore un autre type qui va au delà de l'analyse et cherche des opportunités d'amélioration. Nous observons un large spectre de rôles, responsabilités et compétences nécessaires. Je suspecte que tous dans ce panel sont dans la dernière catégorie, et je pense aussi que quiconque développe une application devrait avoir un intérêt dans la performance de ce qu'il développe, et pas simplement considérer la performance (ou la qualité) comme le travail d'un autre. J'ai une fois entendu un développeur dire "Ce n'est pas mon travail de tester mon code. C'est pour ça que nous avons des équipes de testeurs et d'ingénieurs performance". A mon humble avis, cet ingénieur aurait dû être renvoyé sur le champ !
Martin : La séparation des ingénieurs performance des ingénieurs "normaux" est un énorme anti-pattern. Il échoue pour de nombreuses raisons. Je suis entièrement d'accord sur le fait que la qualité des besoins fonctionnels et non fonctionnels soit du ressort de tous les ingénieurs/programmeurs. Mais en considérant ceci : au cours d'un entretien, j'ai un jour demandé "Quelle est la différence entre une HashMap et une TreeMap ?" J'aurais été entièrement satisfait qu'il me réponde que la HashMap est O(n) alors que la TreeMap est O(log n). J'aurais été ravi qu'il m'explique les différences d'implémentation. Mais la réponse du candidat a été "Les programmeurs n'ont plus besoin de connaître ce genre de choses !". Oui, c'est une bonne chose d'avoir des spécialistes, mais ils doivent coacher le reste de l'équipe pour la mettre à niveau.
Charlie : Je pense que les difficultés vont au delà du tuning de performance, vers l'analyse et l'identification des opportunités d'optimisation. Les choses deviennent plus complexes quand vous passez de la "science" à "l'art" de la performance. Je décrirais la discipline des statistiques d'une façon similaire. Il y a la "science" des statistiques et des méthodes statistiques, et il y a aussi "l'art" d'appliquer les méthodes appropriées". Vous pouvez leur apprendre la science des statistiques, les formules et tout type de calcul, mais leur apprendre l'art d'utiliser le bon outil dans la bonne situation est quelque chose de totalement différent. De façon similaire, nous pouvons leur apprendre la science de la performance, mais l'art de la performance est quelque chose de totalement différent. Je pense que ceux qui luttent avec les performances luttent en fait avec l'art de la performance, et malheureusement, c'est quelque chose qui n'est pas simple à enseigner ou à apprendre.
Kirk : Selon vos définitions, je peux ne pas être d'accord. Quand je pense à "l'art", je pense à quelque chose qui n'est pas mesurable ou ne peut pas être simplement quantifié. Quand je pense aux performances, je pense à quelque chose qui est mesurable et peut être quantifié. Dans mon monde, quand vous dites "art", ce que vous dites vraiment est "je devine". Certaines personnes peuvent être meilleures à deviner que d'autres, mais selon mon expérience, ce n'est pas parce qu'elles sont capables de créer des réponses à partir de rien, mais plutôt qu'elles ont un modèle mental bien développé dans lequel elles peuvent injecter les données disponibles et atteindre une réponse de meilleure qualité. Je le vois dans mon cours quand je soumets un problème qui n'a qu'un ensemble de données minimal et que je vois les développeurs avoir des difficultés. Après qu'ils aient appris un modèle mental, d'un coup cet ensemble de données minimal semble leur hurler la réponse au problème. Les indices sont autour de nous, nous devons juste devenir capables de les reconnaître. Je ne crois pas en cet art, il s'agit plutôt de comprendre ce que les mesures représentent. "L'art" c'est de trouver des façons innovantes d'obtenir plus du matériel avec lequel nous devons travailler.
Charlie : Quand j'ai parlé d'art, je n'ai pas parlé de faire des suppositions. Une des formes de l'art dans l'ingénierie des performances est la reconnaissance de motifs. La description de ce que vous faites dans vos cours, c'est essayer de donner la science de l'ingénierie des performances et ensuite d'enseigner l'art. Le fait de savoir quoi mesurer et monitorer, savoir quel est le seuil pour une métrique est quelque chose qui nécessite plus d'investigation. Savoir quels outils utiliser pour déterminer la cause racine est ce que j'appelle un art. C'est savoir quand appliquer les bonnes méthodes dans la bonne situation. Si c'était une science, elle pourrait être modélisée mathématiquement. Le "modèle mental" tel que vous le décrivez est ce que j'appelle "l'art". Savoir quoi supposer ou spéculer pour réduire le champ des possibilités, ou faire une supposition éclairée grâce aux informations disponibles, ou savoir de quelles données supplémentaires vous avez besoin pour tirer une conclusion tombe dans la catégorie de ce que j'appelle l'art de l'ingénierie des performances.
Kirk : Oui, j'ai constaté qu'une mauvaise habitude est que les gens tirent souvent des conclusions qui ne sont pas corrélées aux données. Ils formulent des hypothèses ou spéculent, ou juste devinent. Je peux vous donner un exemple. Une courbe ascendante dans un graphe de heap, après un cycle de GC implique une fuite mémoire ? Je dirais que c'est une conclusion hâtive basée sur la spéculation. Je peux vous envoyer des logs GC pour lesquels c'est faux. Est-ce que c'est algorithmique ? Je le pense.
Charlie : Une question à se poser est : pourquoi la plupart des universités enseignent aux étudiants en ingénierie logicielle un langage de programmation avant de leur enseigner les mathématiques et la théorie informatique ? Par contraste avec les autres disciplines de l'ingénierie comme la mécanique ou l'industrie, où les étudiants apprennent d'abord les mathématiques et la théorie de leur discipline.
Kirk : Je ne veux pas diminuer l'importance des statistiques, mais souvent les choses qui surviennent dans un ordinateur sont mieux décrites par la théorie des queues. Pour autant que je puisse en juger, très peu de développeurs ou de testeurs connaissent cette théorie. Je ne pense pas que vous ayez besoin d'une compréhension profonde du sujet mais il est nécessaire d'avoir des notions et de savoir comment l'appliquer.
Charlie : J'ai toujours considéré la théorie des queues comme une part de l'étude des statistiques. J'ai été pour la première fois exposé à cette théorie durant un cours de statistiques. Je me rappelle que ce qu'on modélise avec la théorie des queues est basé sur des fonctions de probabilité de densité, par exemple les lois de Poisson, exponentielles, et d'autres.
Martin : Bien qu'en général, je sois d'accord avec Charlie et ses trois volets des compromis sur les performances, je les trouve dommageables dans certains cas. Quand on pense à des runtimes et des GC, oui, cela s'applique bien. Mais quand on pense à des structures de données, une petite empreinte signifie souvent une plus faible latence et de meilleurs débits. Pour fournir un peu de contexte, j'ai travaillé sur des systèmes qui absorbent l'intégralité des flux de marchés financiers nord-américains, qui peuvent supporter des épisodes à plus de 11 millions de messages par seconde. Etant donné l'architecture des serveurs x86 modernes, nous n'avons un support du TLB pour les "larges pages" que sur le cache L1. Le L2 n'a qu'un TLB pour les pages de 4ko. La puce bientôt disponible d'Intel, Haswell, supportera les pages de 2mo pour le L2 quand il sera disponible pour les serveurs l'année prochaine. Quand le reste du code est efficace, cela peut devenir un problème majeur. Nous ne voyons pas le scan des "cards tables" par le GC grâce aux pre-fetchers mais pour la plupart des autres structures de données, c'est un problème majeur. Je pense qu'il y a de bonnes règles générales pour la plupart des cas, mais pour les cas extrêmes, d'autres choses peuvent devenir beaucoup plus importantes.
InfoQ : Dans quels outils et techniques les sociétés devraient investir pour amener l'analyse de performance dans les habitudes ?
Monica : Premièrement, comme je l'ai mentionné, il y a la planification des performances. Ensuite, il y a construire l'infrastructure. Les tests de performance devraient faire partie du cycle de vie du produit. Investir dans une infrastructure de test solide est indispensable. De nombreuses organisations se piègent elles-mêmes en ne prenant pas les devants et avant qu'elles ne s'en rendent compte, elles sont dans l'obligation d'investir plus de ressources pour corriger le tir. Cette attitude est négative, non productive et inefficace pour l'organisation ou ses employés.
Charlie : J'y ai beaucoup pensé récemment. Plusieurs d'entre vous m'ont entendu parler de performance en termes de débit, latence et empreinte. Quand nous devons atteindre les objectifs de performance, il y a huit questions que je pose aux équipes de développement et aux managers.
- Quel est le débit attendu ?
- Quel est le débit le plus bas avec lequel nous pouvons composer (le minimum absolu) et à quelle fréquence le débit peut chuter à ce niveau, et pour quelle durée ?
- Quelle est la métrique du débit, et comment sera-t-elle mesurée ?
- Quelle est la latence attendue, et à quelle fréquence peut-on la dépasser, et pour combien de temps ?
- Quel est la latence maximale ?
- Quelle est la métrique de la latence et comment sera-t-elle mesurée ?
- Quel est la quantité maximale de mémoire qui peut être utilisée ?
- Comment est mesurée l'utilisation mémoire ?
J'ai remarqué que certaines sociétés et organisations échouent à saisir les métriques appropriées. Voici un exemple que j'ai vu récemment, (pas à Salesforce). Supposons que vous souhaitiez diminuer votre empreinte mémoire. Mais le critère de performance n'est pas seulement la réduction de l'empreinte, elle nécessite aussi qu'il n'y ait pas d'augmentation de la consommation CPU, pas de réduction du débit et pas d'augmentation des temps de réponse. Si c'est le cas, ce qui est vraiment voulu, c'est que vous réduisiez l'empreinte mémoire mais sans rien sacrifier au niveau du débit ou de la latence. Bonne chance sur ce coup ! Souligner une amélioration dans une de ces caractéristiques, l'empreinte mémoire dans cet exemple, tout en gardant débit et latence constants va nécessiter un effort de développement énorme ou non-trivial. Rarement, vous pouvez améliorer une des ces caractéristiques sans rien sacrifier dans les autres. Je suis étonné que si peu de monde comprenne ces relations.
Une question similaire est comment l'application sera testée ? Comment vous allez prévoir les usages attendus et projetés en production ? Je pense que vous devez comprendre et caractériser le pire des scénarios, en particulier si vous construisez une plateforme sur laquelle d'autres vont construire des applications. De plus, vous devez aussi comprendre les attentes sur les usages attendus et projetés de l'application en production. Vous devez aussi fermer la boucle entre ce qui est simulé comme charge et comment sont les performances de l'application en production. En d'autres termes, à quel point la charge simulée est efficace pour prédire les performances en production selon ces trois critères de performance ? J'ai rarement observé cette boucle être fermée et mesurer l'efficacité de leurs charges.
Kirk : Bonne liste... J'ajouterais que nous sommes dans une industrie qui souffre de "jalousie du CPU", et que souvent ce n'est pas le CPU le problème. Comprendre les limites fondamentales du matériel que nous utilisons et le relier aux ressources dont nous avons réellement besoin est un problème complexe dont peu se préoccupe.
Je pense que nous allons voir de plus en plus de problèmes de performance qui ne sont pas liés au CPU. Si nous ne les avons pas déjà vécus ou observés, je pense que nous pouvons nous attendre à des problèmes sur des points comme la capacité du bus mémoire ou plus généralement la vitesse à laquelle nous pouvons apporter les données au cache du CPU à partir de la mémoire. La mémoire est le nouveau disque. Un grand défi avec le grand nombre de threads hardware par socket CPU est d'avoir suffisamment de bande passante mémoire et suffisamment de cache CPU. Il y a deux ans, j'ai déjà pu observer un système multicore qui saturait la capacité du bus mémoire avant qu'il n'approche de sa capacité CPU maximale. Combien de personnes aujourd'hui savent comment mesurer la capacité du bus mémoire, ou même y pensent ? Je peux vous donner la réponse à cette dernière question car je la pose tout le temps ... personne ! Et pourtant je rencontre depuis quelques années des applications qui sont limitées par cette ressource.
Martin : Nous avons atteint le point où l'industrie s'est engouffrée trop loin dans une direction. Nous avons poussé pour augmenter la productivité des développeurs et fiabiliser les livraisons, mais cela a un coût. Nous produisons maintenant des logiciels si inefficaces que je ne peux pas imaginer une autre industrie où de tels niveaux d'inefficacité seraient tolérés. A un point tel que nos logiciels pourraient atteindre des débits ou latences 10 ou 100 fois meilleures en utilisant une conception plus propre et du tuning guidé par un profiler. J'ai vu des améliorations de 1000x dans certains cas. Le coût de nos data centers devient significatif et 2-4% des émissions de CO2 sont liés à l'informatique. Nous devons aussi prendre en compte l'explosion des périphériques mobiles sur lesquels un logiciel plus efficace se traduit directement par de l'économie de batterie, et moins de serveurs pour fournir les services mobiles.
A propos des Membres du panel
Ben Evans est CEO de jClarity, une startup qui propose des outils pour aider les développeurs et ops à analyser et améliorer les performances. Il est un des organisateurs pour le LJC (JUG Londres) et membre du JCP Executive Committee, aidant à définir des standards pour l'écosystème Java. Il est aussi Oracle Java Champion, rockstar JavaONE, et co-auteur du livre “The Well-Grounded Java Developer” et orateur régulier sur la plateforme Java, les performances, la concurrence et les sujets liés.
Charlie Hunt est Architecte Performance pour Salesforce.com et auteur principal du livre récent "Java Performance". Avant de rejoindre Salesforce.com, il a été Architecte Performance sur la JVM HotSpot pour Oracle et Sun Microsystems. Il est un orateur régulier sur le sujet de la performance Java à de nombreuses conférences, y compris JavaOne.
Kirk Pepperdine travaille comme Consultant indépendant spécialisé dans le domaine du tuning de performance Java. Il a de plus tenu un séminaire de tuning de performance qui a eu une bonne réception mondiale. Ce séminaire présente une méthodologie de tuning de performance qui peut être utilisée pour améliorer l'efficacité des équipes pour diagnostiquer les problèmes de performance. Nommé Java Champion en 2006, Kirk a publié de nombreux articles et parlé de performance à de nombreuses conférences, y compris Devoxx et JavaONE. Il a aidé à créer Java Performance Tuning, un site renommé comme source d'information sur le tuning de performance. Kirk est aussi contributeur du livre "97 things every programmer should know".
Martin Thompson est spécialiste des hautes performances et basses latences, avec plus de deux décennies d'expérience sur de grands systèmes transactionnels et big data. Il croit en la Mechanical Sympathy, qui est - L'application de la compréhension du matériel est fondamentale pour créer des solutions à hautes-performances élégantes. Le Disruptor est un exemple de ce que sa mechanical sympathy a créé. Martin a été le co-fondateur et CTO de LMAX. Il blog ici, et peut être vu en train de donner des formations sur les performances et la concurrence, ou hackant du code pour améliorer des systèmes.
Monica Beckwith est Oracle performance lead pour le Garbage First Garbage Collector. Elle a travaillé dans l'architecture et les performances pendant plus de 10 ans. Avant Oracle et Sun Microsystems, Monica était responsable des performances pour Spansion Inc. Monica a travaillé avec de nombreux standard benchmarks basés sur Java, avec comme but constant de trouver des opportunités d'amélioration pour la VM HotSpot d'Oracle.