Nous sommes fiers d'annoncer la première version publique de Rally, l'outil de benchmarking que l'équipe d'Elasticsearch utilise en interne depuis plusieurs mois.

Nous voulons partager cet outil avec la communauté, afin de vous aider à émuler les résultats que nous publions dans votre environnement et de vous épauler dans la création de vos benchmarks, sans devoir vous préoccuper d'une multitude de détails.

La genèse de Rally

Rally tire ses origines de scripts Python qui sont les moteurs des benchmarks nocturnes de Elasticsearch et de Lucene's nightly benchmarks.

L'infrastructure de benchmarking permet de pallier les menaces insidieuses (ex. une diminution progressive de la performance). Nous améliorons constamment Elasticsearch dans tous les domaines et accordons beaucoup d'importance à la performance. Imaginez que les développeurs de votre entreprise puissent réaliser eux-mêmes un benchmark pour évaluer l'incidence de leurs modifications durant les premières étapes du développement, plutôt que d'attendre la fusion d'une nouvelle fonctionnalité dans la branche master !

Les développeurs sont généralement inventifs, il est donc possible d'écrire en vitesse un script dans le langage de son choix, l'exécuter pour un cas d'utilisation spécifique et l'oublier. Mais à quelle fréquence vérifions-nous ces chiffres ? 

Ainsi, j'ai changé mon approche et opté pour l'utilisation locale de scripts de benchmarking existants. Cependant, la configuration impliquait beaucoup de manipulations, j'ai donc simplifié l'installation et l'utilisation, et c'est comme ça que Rally a vu le jour.

Que peut faire Rally pour vous ?

Au fil des derniers mois, Rally a pris en charge de plus en plus de fonctionnalités :

Nous pouvons y joindre un système de télémétrie pour une analyse détaillée du comportement de la cible de votre benchmark. Par exemple, Java flight recorder nous a déjà épaulé dans la détection de divers problèmes. Voici quelques exemples de ce que vous pouvez accomplir avec Rally et le système de télémétrie Java flight recorder :

Allocation Profiling

Inspection des « hot classes » dans Elasticsearch.

Nous avons également ajouté un système de télémétrie pour la compilation à la volée, ce qui nous permet d'étudier le comportement du compilateur et par conséquent d'analyser, entre autres, les phases de démarrage durant le benchmarking. Les graphiques ci-dessous montrent le nombre d'événements liés au compilateur à la volée pendant le benchmarking :

L'évaluation de la performance d'un système aussi complexe qu'Elasticsearch présente un problème à différents niveaux. Pour un scénario donné, comme la recherche de logs, la performance pourrait s'améliorer, mais cela pourrait avoir un effet négatif sur la recherche en texte intégral. C'est pourquoi il est possible de définir plusieurs benchmarks (appelés « tracks » dans Rally). Ils sont actuellement directement mis en place le code source de Rally, mais à mesure que l'API se stabilise, nous voulons séparer les « tracks », afin qu'il soit plus facile de définir les vôtres.

Vu que Rally stocke toutes les données statistiques dans Elasticsearch, il est facile de les visualiser avec Kibana. Ainsi, vous pouvez notamment consulter la répartition de l'utilisation du processeur pendant un benchmark :

Pour débuter, nous ajoutons l'ensemble des données de benchmarking à l'index. Puis nous lançons la recherche de benchmarks. Je parie que le moment de la fin de l'indexation vous apparaît clairement.

Nous avons également commencé à exécuter des benchmarks nocturnes en parallèle et nous fournissons les résultats sur le tableau de bord Kibana.

Roadmap

Il y a encore du pain sur la planche : 

Notre principal cheval de bataille est la suppression des restrictions. Nous voulons séparer de Rally les définitions de benchmarks (« tracks ») et offrir plus de flexibilité à Rally pour les processus qu'il met en œuvre lors du benchmark. Actuellement, nous ne prenons en charge qu'un faible nombre de scénarios : tout d'abord, les documents sont indexés en bulk, puis nous exécutons des requêtes basées sur les « tracks ». Par défaut, nous exécutons un benchmark fondé sur des données tirées de geonames.org mais davantage de « tracks » sont disponibles (il suffit de lancer `esrally list tracks`).

Ensuite, nous accordons également beaucoup d'importance à l'amélioration de l'exactitude des mesures. Nous prenons ceci au sérieux et nous avons déjà conscience des possibilités d'amélioration dans certains domaines. Un des problèmes principaux que nous rencontrons est l'omission coordonnée lors de la mesure des temps de latence. Cela veut dire que les requêtes dont le traitement est long empêchent l'outil benchmark d'envoyer d'autres requêtes entre-temps, nous perdons ainsi des échantillons de mesures. Au final, le percentile de distribution du temps de latence rapporté semble plus favorable qu'il ne l'est réellement.

Enfin, Rally est pour l'instant limité aux benchmarks pour une seule machine, mais à l'avenir, nous autoriserons les benchmarks pour un ensemble de machines and early prototypes are already promising.

Exécuter votre premier benchmark

Maintenant, voyons à quel point il est facile d'exécuter un benchmark sur votre propre machine.

En partant du principe que vous avez installé tous les prérequis et que vous avez démarré la fonction de stockage des statistiques de Rally, il ne vous reste que 3 étapes pour obtenir vos premiers résultats de benchmark :

pip3 install esrally
esrally configure
esrally --pipeline=from-distribution --distribution-version=5.0.0-alpha1

Si vous souhaitez en savoir plus sur Rally, rendez-vous sur la page Web des projets Rally, jetez un œil à la liste des bugs ou aidez nous en contribuant vos "tracks" ou vos modifications de Rally.

L'image en haut de cette publication a été fournie par Andrew Basterfield sous la license CC BY-SA (source originale). L'image a été colorisée différemment de l'originale mais demeure autrement inchangée.