KeyDB : le fork multithread de Redis

Chez Hosted Power, nous voulons nous distinguer en matière de performances. Nous nous efforçons d’être les plus rapides et les plus performants du marché.

Par conséquent, l’innovation est une nécessité intégrée à notre organisation afin de continuer à améliorer nos processus et nos outils, qui créent ces environnements performants pour votre ou vos sites web.

C’est ici que Redis entre en jeu. Il s’agit d’un datastore en mémoire utilisé pour la mise en cache dans notre environnement. Il nous permet d’accéder rapidement aux données et de les récupérer sans devoir accéder au disque, ce qui garantit des temps de réponse minimaux.

Pendant longtemps, la communauté a encouragé Redis à rendre son système multithread, mais pour des raisons telles que la facilité de programmation et le déploiement économique, Redis a décidé de conserver son architecture monothread.

Des alternatives multithread au système de mise en cache ont finalement commencé à apparaître, incitant également les environnements professionnels à étudier et à tester ces solutions.

Comme nous avons constaté que les résultats de benchmarks réalisés sur ces alternatives affichaient des performances 5 à 25 fois supérieures à celles que Redis devrait atteindre, nous avons commencé nos propres tests. Une alternative s’est révélée être la plus stable et la plus compatible avec un environnement professionnel : KeyDB.

KeyDB est un fork multithread de Redis, ce qui signifie qu’il est entièrement compatible avec le protocole, les modifications et les modules de Redis, tout en promettant de rester aligné sur les évolutions futures de Redis.

En plus d’être multithread, KeyDB offre de meilleures performances avec moins de matériel, une réduction de la taille du cluster grâce à la réplication active (c’est-à-dire 2 nœuds maîtres qui acceptent tous deux les opérations de lecture et d’écriture), la possibilité de créer vos propres commandes avec ModJS, ainsi que des fonctionnalités à venir intéressantes telles que le stockage FLASH, la prise en charge de json et la prise en charge de plusieurs locataires. Tout cela semble prometteur, mais nous devons encore confirmer ces attentes grâce aux résultats de nos propres tests.

Pour obtenir les meilleurs résultats de test possibles, nous avons utilisé un outil de benchmark développé et utilisé par RedisLabs, appelé memtier_benchmark. Il permet de générer différents modèles de trafic sur des instances Redis. Nous avons ainsi pu recréer différents scénarios, en faisant varier le nombre de clients et la quantité de requêtes générées par ces clients dans différentes configurations, allant d’une configuration 2XCPU-4GB RAM à une configuration 8xCPU-32GB RAM.

Les résultats n’ont pas déçu. Nous avons commencé les tests dans un environnement doté de seulement 2 cœurs et de 4GB RAM. Nous avons utilisé 100 clients, chacun générant 100, 1000 et 10 000 requêtes.

Comme le montrent les résultats, Redis surpasse largement KeyDB tout en conservant une latence moyenne plus faible.

Ces résultats étaient prévisibles, car KeyDB devrait s’améliorer considérablement à mesure que davantage de threads lui sont attribués. Les tests réalisés avec 4 cœurs confirment déjà cette hypothèse :

À partir de 4 cœurs, KeyDB commence à surpasser Redis sur toutes les métriques, exécute 66 % d’opérations supplémentaires par seconde et atteint un débit de données par seconde supérieur à celui de Redis. Comme prévu, l’augmentation du nombre de threads à 6 a donné des résultats encore meilleurs.

KeyDB double les valeurs que Redis peut produire en matière de débit de données et d’opérations par seconde. Une tendance claire se dessine ici. Pour la confirmer, nous avons une nouvelle fois augmenté le nombre de threads, jusqu’à 8.

Nous pouvons en tirer certaines conclusions : la solution devient avantageuse à partir d’une configuration d’au moins 4 cœurs, tandis que le meilleur rendement est toujours obtenu avec une configuration de 6 threads. La latence n’est pas une métrique présentée dans les graphiques ci-dessus, mais les résultats des tests montrent que KeyDB conserve une latence moyenne plus faible.

L’avenir de cette alternative est prometteur. Puisqu’elle surpasse déjà une configuration Redis optimisée, nous chercherons prochainement à l’intégrer à notre déploiement. Cette fonctionnalité permettra aux sites web hébergés sur notre TurboStack® d’être encore plus performants.