Partager via

Tests de performances avec Azure Managed Redis (préversion)

  • Article

Le test des performances d’une instance Redis peut être une tâche compliquée. Les performances d’une instance Redis peuvent varier en fonction de paramètres tels que le nombre de clients, la taille des valeurs de données et l’utilisation éventuelle du pipelining. Il peut également y avoir un compromis entre l’optimisation du débit ou de la latence.

Heureusement, plusieurs outils existent pour faciliter l’évaluation de Redis. Deux des outils les plus populaires sont redis-benchmark et memtier-benchmark. Cet article se concentre sur memtier_benchmark, souvent appelé memtier.

Guide pratique pour utiliser l’utilitaire memtier_benchmark

  1. Installez memtier sur une machine virtuelle cliente que vous pouvez utiliser pour les tests. Suivez la documentation Memtier pour obtenir des instructions sur l’installation de l’image open source.

  2. La machine virtuelle cliente utilisée pour les tests doit se trouver dans la même région que votre instance Azure Managed Redis (AMR).

  3. Assurez-vous que la machine virtuelle cliente que vous utilisez possède au moins autant de puissance de calcul et de bande passante que l’instance de cache testée.

  4. Configurez vos paramètres d’isolation réseau et de pare-feu de machines virtuelles pour vous assurer que la machine virtuelle cliente peut accéder à votre instance d’Azure Managed Redis.

  5. Si vous utilisez TLS/SSL sur votre instance de cache, vous devez ajouter les paramètres --tls et --tls-skip-verify à votre commande memtier_benchmark.

  6. memtier_benchmark utilise le port 6379 par défaut. Utilisez le paramètre -p 10000 pour remplacer ce paramètre, car AMR utilise plutôt le port 10 000.

  7. Pour toutes les instances d’Azure Managed Redis utilisant la stratégie de cluster OSS, vous devez ajouter le paramètre --cluster-mode à votre commande memtier. Les instances d’AMR utilisant la stratégie de cluster Enterprise peuvent être traités comme des caches non cluster et n’ont pas besoin de ce paramètre.

  8. Lancez memtier_benchmark à partir de l’interface CLI ou de l’interpréteur de commandes de la machine virtuelle. Pour obtenir des instructions sur la configuration et l’exécution de l’outil, consultez la documentation Memtier.

Recommandations d’évaluation

  • Si vous n’obtenez pas les performances dont vous avez besoin, essayez d’effectuer un scale-up vers un niveau plus avancé. Le niveau Équilibré a généralement deux fois plus de processeurs virtuels que le niveau À mémoire optimisée, et le niveau Optimisé pour le calcul a généralement deux fois plus de processeurs virtuels que le niveau Équilibré. Azure Managed Redis étant basé sur Redis Enterprise plutôt que sur Redis Community, le processus Redis principal est capable d’utiliser plusieurs processeurs virtuels. Par conséquent, les instances avec plus de processeurs virtuels offrent de meilleures performances de débit.

  • Le scale-up à des tailles de mémoire supérieures ajoute également davantage de processeurs virtuels, ce qui augmente les performances. Toutefois, le scale-up à des tailles de mémoire supérieures est généralement moins efficace que l’utilisation d’un niveau plus performant. Pour obtenir une description détaillée des processeurs virtuels disponibles pour chaque taille et niveau, consultez Niveaux et références SKU en un clin d’œil.

  • L’évaluation du niveau Flash optimisé peut être difficile, car certaines clés sont stockées sur DRAM tandis que d’autres sont stockées sur un disque flash NVMe. Les clés du benchmark DRAM sont presque aussi rapides que les autres instances Azure Managed Redis, mais les clés du disque flash NVMe sont plus lentes. Étant donné que le niveau Flash optimisé place intelligemment les clés les plus utilisées sur la DRAM, vous devez veiller à ce que votre configuration de référence corresponde à l’utilisation réelle attendue.

  • L’utilisation de TLS/SSL diminue les performances de débit, mais est fortement recommandée en tant que meilleure pratique de production.

  • Il est essentiel de remplir d’abord l’instance Redis avec des données avant de procéder à un benchmarking. Le benchmarking sur un cache vide produit des résultats sensiblement meilleurs que ceux que vous pourriez observer dans la pratique.

  • Le nombre de connexions utilisées a un effet significatif sur le benchmark. L’utilisation d’un trop grand nombre de connexions commence à dégrader les performances du cache. L’utilisation d’un nombre trop faible de connexions n’illustre pas les performances complètes du cache. Nous vous recommandons de configurer le nombre de connexions en fonction des besoins réels de votre application. Vous déterminez le nombre total de connexions en multipliant le nombre de clients par le nombre de threads.

  • La configuration du pipeline a un effet significatif sur les tests de performances. Si vous définissez le paramètre de pipeline sur une valeur plus élevée, vous observerez une augmentation du débit, mais aussi une dégradation de la latence. Pour plus d’informations, consultez Traitement en pipeline.

Exemples memtier_benchmark

Remarque

Cet exemple montre un benchmarking sur une instance Optimisé pour le calcul X3 utilisant la stratégie de cluster OSS et le protocole TLS.

Configuration de pré-test : préparez l’instance de cache avec les données requises pour les tests. Le chargement de l’instance avec des données garantit que les résultats reflètent plus précisément les conditions réelles. Le paramètre {number-of-keys} doit être déterminé par la taille de votre instance AMR et la taille de chaque clé. En règle générale, il convient de remplir l’instance à environ 75 %, en prenant en compte les mémoires tampons. Vous pouvez utiliser cette formule : numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300). Par exemple, si vous effectuez un benchmark sur une instance Optimisé pour le calcul X3, utilisant des tailles de clé de 1 024 octets, comme indiqué précédemment, cela implique {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300). Le résultat est égal à environ 1 699 396 clés.

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 --key-maximum=1699396 -n allkeys --key-pattern=P:P --ratio=1:0 -data-size=1024 --tls --cluster-mode

Remarque

Cet exemple utilise les indicateurs --tls, --tls-skip-verify et --cluster-mode. Vous n’en avez pas besoin si vous utilisez respectivement Azure Managed Redis en mode non-TLS ou si vous utilisez la stratégie de cluster Entreprise.

Pour tester le débit : cette commande teste des requêtes GET en pipeline avec une charge utile de 1 Ko. Utilisez cette commande pour tester le débit de lecture auquel s’attendre de la part votre instance de cache. Cet exemple part du principe que vous utilisez TLS et la stratégie de cluster OSS. Le paramètre --key-pattern=R:R garantit que les clés sont sollicitées de manière aléatoire, ce qui augmente le réalisme du benchmark. Ce test s’exécute pendant cinq minutes.

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 -d 1024 --key-maximum=1699396 --key-pattern=R:R --ratio=0:1 --distinct-client-seed --test-time=300 --json-out-file=test_results.json --tls --tls-skip-verify --cluster-mode

Exemples de données de référence de performances

Les tableaux suivants montrent les valeurs de débit maximales qui ont été observées lors du test de différentes tailles d’instances d’Azure Managed Redis. Nous avons utilisé memtier_benchmark à partir d’une machine virtuelle Azure IaaS par rapport au point de terminaison Azure Managed Redis, en utilisant les commandes memtier indiquées dans la section Exemples memtier_benchmark. Les numéros de débit concernent uniquement pour les commandes GET. En règle générale, les commandes SET ont un débit inférieur. Les performances réelles varient en fonction des commandes et de la configuration Redis. Ces chiffres sont fournis en guise de point de référence, et non comme garantie.

Attention

Ces valeurs ne sont pas garanties et il n’y a pas de contrat SLA pour ces chiffres. Nous vous recommandons vivement d’effectuer vos propres tests de performances pour déterminer la taille de cache appropriée pour votre application. Ces chiffres peuvent changer au fur et à mesure que nous publions des résultats plus récents.

Important

Microsoft met régulièrement à jour la machine virtuelle sous-jacente utilisée dans des instances de cache. Cela peut modifier les caractéristiques du niveau de performance de cache en cache et de région en région. Les exemples de valeurs du point de référence dans cette page reflètent le matériel de cache de génération plus ancien dans une unique région. Vous pouvez observer des résultats meilleurs ou différents dans la pratique, en particulier en terme de bande passante réseau.

Azure Managed Redis offre un choix de stratégie de cluster : Enterprise et OSS. La stratégie de cluster Enterprise est une configuration plus simple qui ne nécessite pas que le client prenne en charge le clustering. La stratégie de cluster OSS, en revanche, utilise le protocole de cluster Redis pour prendre en charge un débit plus élevé. Nous vous recommandons d’utiliser la stratégie de cluster OSS dans la plupart des cas. Pour plus d’informations, consultez Clustering.

Les points de référence pour les deux stratégies de cluster sont indiqués dans les tableaux suivants. Pour le tableau de stratégie de cluster OSS, deux configurations de benchmarking sont fournies :

  • 300 connexions (50 clients et 6 threads)
  • 2 500 connexions (50 clients et 50 threads)

Les deuxièmes benchmarks sont fournis, car 300 connexions ne sont pas suffisantes pour illustrer entièrement les performances des instances de cache plus volumineuses.

Voici le débit lors des opérations GET par seconde sur une charge utile de 1 Ko pour les instances AMR, ainsi que le nombre de connexions clientes utilisées pour le benchmarking. Tous les chiffres ont été calculés pour des instances AMR avec des connexions SSL, et la bande passante réseau est notée en Mbits/s.

Stratégie de cluster OSS

Taille en Go Processeur virtuel/Bande passante réseau/À mémoire optimisée Processeur virtuel/Bande passante réseau/Équilibré Processeur virtuel/Bande passante réseau/Calcul optimisé
1 - 2/5 000/103 500 -
3 - 2/2 000/104 500 4/10 000/221 100
6 - 2/2 000/106 500 4/10 000/210 850
12 2/2 000/106 000 4/4 000/223 900 8/12 500/499 900
24 4/4 000/227 800 8/8 000/495 300 16/12 500/485 920
60 8/8 000/496 000 16/10 000/476 500 32/16 000/454 200
120 16/10 000/476 200 32/16 000/462 200 64/28 000/463 800

Stratégie de cluster Enterprise

Taille en Go Processeur virtuel/Bande passante réseau/À mémoire optimisée Processeur virtuel/Bande passante réseau/Équilibré Processeur virtuel/Bande passante réseau/Calcul optimisé
1 - 2/5 000/56 900 -
3 - 2/2 000/56 900 4/10 000/118 900
6 - 2/2 000/59 200 4/10 000/111 950
12 2/2 000/55 800 4/4 000/118 500 8/12 500/206 500
24 4/4 000/122 000 8/8 000/205 500 16/12 500/294 700
60 8/8 000/208 100 16/10 000/293 400 32/16 000/441 400
120 16/10 000/285 600 32/16 000/451 700 64/28 000/516 200