JCrete 2013 – The perils of benchmarking

Durant cette session, Kirk Pepperdine a évoqué les différents risques liés au benchmarking. Le sujet était très vaste et les discussions très avancées. En voici un compte rendu.

Les aspects sous-estimés d’un exercice de benchmarking sont nombreux, parmi lesquels des questions :

• Quel type de benchmark est-on en train de produire ?
• Comment garantissons-nous que le harnais de test ne comporte pas de goulot d’étranglement ?
• Comment interprétons-nous les résultats de notre benchmark ?

Tout d’abord, Kirk nous a expliqué la différence entre un benchmark au sens marketing du terme et un benchmark tel que le voient les développeurs. Si un benchmark montrera toujours les faiblesses d’un système, il suffit de modifier la fenêtre de mesure ou de tuner le système de sorte que les faiblesses soient en dehors de la plage de mesure. C’est ce que les départements marketing font tous les jours. Les développeurs quant à eux tentent de provoquer ces faiblesses pour pouvoir les résoudre. Les benchmarks qui prétendent démontrer la supériorité de telle solution par rapport à telle autre entrent bien sûr dans la catégorie "Marketing".

Martin Thompson indique ensuite que l’une des étapes de base d’un benchmark consiste à remplacer le système à tester par un no-op. Si le benchmark renvoie des temps de réponse supérieurs à zéro, c’est que le harnais de test ne mesure pas la bonne chose et qu’il doit être revu.

Une autre astuce proposée par Peter Lawrey est de démarrer la mesure au timestamp auquel la requête aurait dû partir, plutôt que le timestamp réel auquel elle a été envoyée au serveur. De fait, tout problème dans le harnais de test se manifestera par des mauvais résultats. Par exemple, si vous envoyez 10 requête par secondes à votre serveur pendant 10 secondes, mais que votre harnais a un Full GC de 2 secondes en plein milieu du test, cela veut dire que vous avez mesuré la capacité de votre serveur à tenir 8.1 requêtes par secondes (100 requêtes en 12 secondes). Avec l’approche de Peter, vous verrez qu’il y a un problème par de mauvais temps de réponse.

Le problème de cette approche est que quasiment tous les benchmarks seraient désastreux, si elle était utilisée. Ceci montre d’ailleurs à quel point les benchmarks publics doivent être lus avec un regard critique. Kirk a souligné que tout benchmark qui ne mentionne que le temps de réponse moyen est par définition faux.

Il est possible que le harnais de test limite lui-même la charge maximale imposée au système. Ainsi, la quasi totalité des benchmarks proposés par l’organisation SPEC sont faux. Par exemple, la charge générée par le benchmark SPECjms dépend directement de la vitesse d’écriture du disque dur de la machine qui exécute le harnais de test. Les résultats ne sont donc pas exploitables.

Le problème est d’ailleurs souvent reproché au framework JMeter qui utilise énormément de ressources pour générer une charge de tests. Gatling et The Grinder ont été évoqués mais jugés insuffisants. Martin Thompson nous a indiqué être tout d’abord revenu aux bases avec Apache Bench, puis avoir écrit lui-même son propre injecteur pour ne souffrir d’aucun problème de performance.

Plutôt que d’écrire des benchmarks, que diriez-vous d’utiliser vos tests d’acceptance comme base de benchmark ? En changeant juste le driver (JUnit/Cucumber/…) pour que ces tests s’exécutent de manière hautement parallèle, vous obtiendrez des résultats très surprenants !

Enfin, nous avons souligné l’importance d’avoir un regard critique sur les résultats d’un benchmark. Par exemple, penser que le temps de réponse d’un système dépend de la charge qui lui est imposé est une hypothèse fausse, il suffit de tracer la courbe des temps de réponse pour s’en rendre compte. De la même manière, considérer que cette courbe suit une distribution gaussienne est une erreur car elle dépend de très nombreux facteurs, notamment de la notion de travail accumulé (reconstruction d’index, GC, …).

Alex Snaps a résumé ceci en expliquant que si, en tant que développeurs, nous ne savions pas tuner nos benchmarks pour que les résultats aient l’air bons, nous devrions changer de métier.

Cette session s’est joyeusement terminée autour d’un troll sur les frameworks de logging dont cette perle : "Log4J (2) est la plus mauvaise implémentation possible d’un framework de log, si l’on ignore toutes les autres !"