Même les ensembles de données les plus modestes peuvent profiter des performances les plus rapides

Même les ensembles de données les plus modestes peuvent profiter des performances les plus rapides

Ceux d’entre nous qui les utilisent savent que Redis et Memcached ont été conçus dès le départ pour atteindre le débit le plus élevé et la latence la plus faible pour les applications, et ce sont en fait les systèmes de stockage de données les plus rapides disponibles aujourd’hui. Ils servent les données de la RAM et exécutent toutes les opérations simples (telles que SET et GET) avec une complexité O (1). Cependant, lorsqu’il est exécuté sur une infrastructure cloud telle qu’AWS, Redis ou Memcached, il peut subir des variations de performances importantes entre différentes instances et plates-formes, ce qui peut affecter considérablement les performances de votre application. En tant que fournisseur de services cloud pour l’hébergement d’ensembles de données Redis et Memcached, chez Garantia Data, nous recherchons toujours les meilleures pratiques pour optimiser les performances, et nous avons donc récemment effectué un test de référence pour comparer les petites et moyennes tailles (<= 12 Go) Redis et Ensembles de données Memcached s'exécutant sur différentes instances et plates-formes AWS.

Considérations architecturales

La première chose que nous avons examinée lors de la constitution de notre benchmark a été les différentes alternatives architecturales que nous voulions comparer. Les utilisateurs choisissent généralement l’instance AWS la plus économique en fonction de l’estimation de la taille initiale de leur ensemble de données, cependant, il est également crucial de garder à l’esprit que d’autres utilisateurs AWS peuvent partager le même serveur physique qui exécute vos données (comme l’a bien expliqué Adrian Cockcroft ici). Cela est particulièrement vrai si vous avez un jeu de données petit à moyen, car les instances entre m1.small et m1.large sont beaucoup plus susceptibles d’être partagées sur un serveur physique que les grandes instances comme m2.2xlarge et m2.4.xlarge, qui s’exécutent généralement sur un serveur physique dédié. Vos « voisins » peuvent devenir « bruyants » une fois qu’ils commencent à consommer des ressources d’E/S et de processeur excessives de votre serveur physique. De plus, les petites et moyennes instances sont par nature plus faibles en puissance de traitement que les grandes instances. Votre sélection d’instance peut avoir un effet important sur les performances de votre Redis/Memcached, qui utilise généralement un nombre optimal de lignes de code pour exécuter chaque commande. Toute légère interférence d’un “voisin bruyant” ou manque de puissance de traitement qui retarde les opérations (telles que l’accès à la mémoire, la transmission réseau ou le changement de contexte) peut réduire considérablement le débit et augmenter la latence. Pour cette raison, il est raisonnable de supposer que les applications utilisant des instances AWS petites à moyennes pour leurs données Redis ou Memcached sont plus sujettes à la dégradation des performances. Une autre façon d’exécuter Redis ou Memcached sur AWS consiste à utiliser un service, tel que AWS Élasticache (pour Memcached), ou le nôtre Nuage Redis ou Cloud Memcaché. Cependant, lors de l’utilisation d’Elasticache, l’utilisateur doit toujours sélectionner la taille de l’instance et peut donc souffrir des mêmes problèmes de performances. Redis Cloud et Memcached Cloud de Garantia Data utilisent une approche différente : nous exécutons tous les nœuds du cluster sur des instances m2.2xlarge ou m2.4xlarge pour garantir les meilleures performances, mais nous facturons uniquement les utilisateurs en fonction de la taille réelle de leur ensemble de données (en Go). Pour tous les détails sur la façon dont nous avons configuré le benchmark, y compris les ressources, les ensembles de données et la configuration, n’hésitez pas à sauter à la fin de l’article.

Résultats des tests de référence

Sans plus tarder, voici ce que nous avons découvert sur la façon dont les alternatives pour exécuter Redis et Memcached sur AWS se comparent en termes de performances.

Débit

1

Remarque : ElastiCache utilise 2 threads Memcached sur l’instance m1.large et 4 sur l’instance m1.xlarge, tandis que Redis autonome est basé sur une architecture à thread unique Comme vu ci-dessus, le RPS de Garantia Data Memcached/Redis Cloud était meilleur dans la plage de 25 à 100 % (selon le type d’instance) qu’ElastiCache ou Stand-alone Redis.

Latence

Nous avons également constaté un temps de réponse supérieur à la moyenne avec notre cluster Memcached/Redis Cloud de l’ordre de 25 à 50 % par rapport à ElastiCache ou à Redis autonome, tandis que son temps de réponse de 99 % en mosaïque était nettement meilleur, de l’ordre de x6- x30, qu’ElastiCache ou Redis autonome. 2 3

Remarque : Notre mesure du temps de réponse prend en compte l’aller-retour réseau, le temps de traitement Redis/Memcached et le temps nécessaire à l’outil memtier_benchmark pour analyser le résultat.

Conclusion

Ce benchmark démontre qu’une approche architecturale différente peut améliorer le débit et réduire considérablement la latence de Redis et Memcached dans le cloud. Nous pensons que ces résultats s’expliquent par l’architecture unique de nos services Redis Cloud et Memcached Cloud. Chez Garantia Data, nous avons développé plusieurs technologies qui s’exécutent sur chaque nœud de nos clusters et garantissent une interférence minimale entre les utilisateurs, c’est-à-dire :

  • Migrer des ensembles de données « bruyants » d’un nœud à un autre
  • Repartitionnement des ensembles de données “bruyants” pour de meilleures performances et moins d’interférences

Dans les coulisses, nous surveillons chaque commande Redis ou Memcached et comparons constamment son temps de réponse à ce qui devrait être une valeur optimale. De plus, nous repartissons les ensembles de données à la volée de manière non intrusive, ce qui est une opération très difficile avec des mécanismes de synchronisation complexes entre plusieurs éléments distribués. Cette architecture permet aux utilisateurs de n’importe quelle taille d’ensemble de données (y compris les tailles petites à moyennes) de s’exécuter sur les instances les plus puissantes et de profiter des meilleures performances, tout en ne payant que pour leur Go réel utilisé sur une base horaire – afin que nos clients obtiennent le meilleur de les deux mondes.

Configuration du test de référence

Nous savons que vous voulez connaître les moindres détails de notre référence, alors voici les ressources que nous avons utilisées :

  • ElastiCache sur les instances m1.small, m1.large, m1.xlarge
  • Redis autonome sur les instances m1.small, m1.large, m1.xlarge
  • Un cluster Garantia Data Redis/Memcached Cloud (exécuté sur la même plateforme technologique) sur des instances m2.4xlarge

Voici notre configuration pour générer la charge :

  • Pour ElastiCache et les tests Redis autonomes — instance m2.2xlarge qui a exécuté notre memtier_benchmark outil de génération de charge (un outil de génération de charge avancé que nous avons développé, que nous partagerons bientôt dans notre github Compte).
  • Pour les tests Garantia Data Redis/Memcached Cloud — 2 instances m2.2xlarge qui ont exécuté le memtier_benchmark outil, un pour simuler la charge et analyser les résultats, et l’autre pour créer une charge de fond qui simule des voisins bruyants.

4

Nous avons exécuté chacun des tests 3 fois sur chaque configuration et calculé les résultats moyens en utilisant les paramètres suivants :

  1. 100 connexions
  2. Taille d’objet 100B
  3. Ratio 50/50 GET/SET (pour Redis et Memcached)

Nos tailles de jeu de données comprenaient :

  • 0,5 Go pour l’instance m1.small
  • 5 Go pour l’instance m1.large
  • 12 Go pour l’instance m1.xlarge
  • Toute combinaison des éléments ci-dessus pour le cluster Garantia Data Redis/Memcached Cloud

Configuration d’ElastiCache
Version du moteur de cache : 1.4.5
Région Amazon : US-EST-1
Instances Amazon testées : m1.small, m1.large, m1.xlarge

Configuration Redis autonome

Version Redis : 2.4.17
Système d’exploitation : Ubuntu 12.04 LTS (64 bits)
Noyau : 3.2.0-23-virtuel
Région Amazon : US-EST-1
Instances Amazon testées : m1.small, m1.large, m1.xlarge

Configuration Redis Cloud / Memcached Cloud

Version Redis : 2.4.15
Version Memcache : 1.4.15
Système d’exploitation : Ubuntu 12.04 LTS (64 bits)
Noyau : 3.2.0-23-virtuel
Région Amazon : US-EST-1
Instances de cluster Amazon testées : m2.4xlarge

Configuration de memtier_benchmark

Édition : 2.2.0-11
Système d’exploitation : Ubuntu 12.04 LTS (64 bits)
Noyau : 3.2.0-23-virtuel
Région Amazon : US-EST-1
Instances Amazon testées : m2.2xlarge

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *