Partager via

Tests de performances

  • 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 redis-benchmark.

Utilisation de l’utilitaire redis-benchmark

  1. Installez le serveur Redis open source sur des machines virtuelles clientes que vous pouvez utiliser pour le test. L’utilitaire redis-benchmark est intégré à la distribution Redis open source. Suivez la documentation Redis pour obtenir des instructions sur l’installation de l’image open source.

  2. La machine virtuelle cliente utilisée pour le test doit figurer dans la même région que votre instance d’Azure Cache pour Redis.

  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 pour vous assurer que la machine virtuelle cliente peut accéder à votre instance Azure Cache pour Redis.

  5. Si vous utilisez TLS/SSL sur votre instance de cache, vous devez ajouter le paramètre --tls à votre commande redis-benchmark ou utiliser un proxy comme stunnel.

  6. Redis-benchmark utilise le port 6379 par défaut. Utilisez le paramètre -p pour remplacer ce paramètre. Vous devez utiliser -p, si vous utilisez le protocole SSL/TLS (port 6380) ou si vous utilisez le niveau Enterprise (port 10000).

  7. Si vous utilisez une instance Azure Cache pour Redis qui utilise le clustering, vous devez ajouter le paramètre --cluster à votre commande redis-benchmark. Les caches de niveau Entreprise utilisant le Clustering Entreprise peuvent être traités comme des caches non mis en cluster et n’ont pas besoin de ce paramètre.

  8. Lancez redis-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 redis-benchmark et les sections Exemples redis-benchmark.

Recommandations d’évaluation

  • Il est important de ne pas tester les performances de votre cache uniquement dans des conditions d’état stable. Testez également les conditions de basculement, et mesurez la charge UC/Serveur de votre cache pendant ce temps. Vous pouvez commencer un basculement en redémarrant le nœud principal. Tester dans des conditions de basculement vous permet de voir comment votre application se comporte en matière de débit et de latence dans une situation de basculement. Un basculement peut se produire pendant des mises à jour et au cours d’un événement non planifié. Dans l’idéal, vous ne souhaitez pas voir un pic de charge UC/Serveur dépassant 80 %, même en cas de basculement, compte tenu de l’impact que cela peut avoir sur les performances.

  • Envisagez d’utiliser des instances Azure Cache pour Redis de niveaux Enterprise et Premium. Ces tailles de cache offrent une meilleure latence de réseau et un débit supérieur, car les instances s’exécutent sur un matériel plus performant.

  • Le niveau Enterprise offre généralement les meilleures performances, car Redis Enterprise permet au processus Redis principal d’utiliser plusieurs processeurs virtuels. Les niveaux basés sur Redis open source, tels que Standard et Premium, ne peuvent utiliser qu’un seul processeur virtuel pour le processus Redis par partition.

  • L’évaluation du niveau Enterprise Flash 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 qu’une instance niveau Enterprise, mais les clés du disque flash NVMe sont plus lentes. Étant donné que le niveau Enterprise Flash place intelligemment les clés les plus utilisées en DRAM, assurez-vous que votre configuration de référence correspond à l’utilisation réelle attendue. Envisagez d’utiliser le paramètre -r pour définir de manière aléatoire les clés auxquelles vous accédez.

  • L’utilisation de TLS/SSL réduit les performances de débit, ce qui peut être clairement vu dans l’exemple de données d’évaluation dans les tableaux suivants.

  • Même si un serveur Redis est monothread, le scale-up tend à améliorer les performances de débit. Les processus système peuvent utiliser les processeurs virtuels supplémentaires au lieu de partager le processeur virtuel utilisé par le processus Redis. Le scale-up est particulièrement utile sur les niveaux Enterprise et Enterprise Flash, car Redis Enterprise n’est pas limité à un seul thread.

  • Sur le niveau Premium, un scale-out, clustering, est généralement recommandé avant d’effectuer un scale-up. Le clustering permet au serveur Redis d’utiliser davantage de processeurs virtuels en partitionnant les données. Dans ce cas, le débit doit augmenter à peu près linéairement lors de l’ajout de partitions.

  • Sur les caches standard C0 et C1, lorsque l’analyse interne de Defender est en cours sur les machines virtuelles, vous pouvez observer de courtes pointes de la charge du serveur qui ne sont pas dues à une augmentation des demandes de cache. Vous constatez une latence plus élevée pour les demandes lorsque des analyses internes de Defender sont exécutées sur ces niveaux plusieurs fois par jour. Les caches sur les niveaux C0 et C1 n’ont qu’un seul cœur pour le multitâche, divisant le travail pour servir l’analyse antivirus interne et les requêtes Redis. Vous pouvez réduire l’effet en effectuant une mise à l’échelle vers une offre de niveau supérieur avec plusieurs cœurs d’UC, tels que C2.

    La taille accrue du cache sur les niveaux supérieurs permet de résoudre les problèmes de latence. En outre, au niveau C2, vous pouvez prendre en charge autant de 2 000 connexions clientes.

Exemples Redis - benchmark

Configuration de pré-test : Préparez l’instance de cache avec les données requises pour les commandes de test de la latence et du débit :

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024

Pour tester la latence : Testez les requêtes GET avec une charge utile de 1 Ko :

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4

Pour tester le débit : Requêtes GET en pipeline avec une charge utile de 1 Ko :

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

Pour tester le débit d’un cache de niveau De base, Standard ou Premium à l’aide de TLS : Requêtes GET en pipeline avec une charge utile de 1 ko :

redis-benchmark -h yourcache.redis.cache.windows.net -p 6380 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --tls

Pour tester le débit d’un cache Enterprise Flash ou Enterprise sans TLS à l’aide du mode cluster OSS : Requêtes GET en pipeline avec une charge utile de 1 ko :

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --cluster

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 de caches Standard, Premium, Enterprise et Enterprise Flash. Nous avons utilisé redis-benchmark et memtier-benchmark à partir d’une machine virtuelle IaaS sur le point de terminaison Azure Cache pour Redis. 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. Ces nombres sont optimisés pour le débit. Le débit réel dans des conditions de latence acceptables peut être inférieur.

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 consulter des résultats meilleurs ou différents dans la pratique.

La configuration suivante a été utilisée pour évaluer le débit des niveaux De base, Standard et Premium :

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

Benchmarks Redis de niveau standard

Instance Taille Processeurs virtuels Bande passante réseau attendue (Mbit/s) Requêtes GET par seconde sans SSL (taille de valeur de 1 Ko) Requêtes GET par seconde avec SSL (taille de valeur de 1 Ko)
C0 250 Mo Partagé 100 15,000 7 500
C1 1 Go 1 500 38 000 20 720
C2 2,5 Go 2 500 41 000 37 000
C3 6 Go 4 1 000 100 000 90 000
C4 13 Go 2 500 60 000 55 000
C5 26 Go 4 1 000 102 000 93 000
C6 53 Go 8 2 000 126 000 120 000

Benchmarks Redis de niveau premium

Instance Taille Processeurs virtuels Bande passante réseau attendue (Mbit/s) Requêtes GET par seconde sans SSL (taille de valeur de 1 Ko) Requêtes GET par seconde avec SSL (taille de valeur de 1 Ko)
P1 6 Go 2 1 500 180 000 172 000
P2 13 Go 4 3 000 350 000 341 000
P3 26 Go 4 3 000 350 000 341 000
P4 53 Go 8 6 000 400 000 373 000
P5 120 Go 32 6 000 400 000 373 000

Important

Les instances P5 des régions Chine Est et Chine Nord utilisent 20 cœurs, et non 32 cœurs.

Niveaux Enterprise et Enterprise Flash

Les niveaux Enterprise et Enterprise Flash offrent 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 des débits plus élevés. 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.

La configuration suivante a été utilisée pour évaluer le débit des niveaux Flash Entreprise et Entreprise :

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 10000000 -d 1024 -P 50 -c 50 --threads 32

Notes

Cette configuration est quasi identique à celle utilisée pour évaluer les niveaux De base, Standard et Premium. La configuration précédente, toutefois, n’a pas utilisé entièrement les performances de calcul supérieures des niveaux Entreprise. Des demandes et des threads supplémentaires ont été ajoutés à cette configuration afin d’illustrer toutes les performances.

Stratégie de cluster Enterprise
Instance Taille Processeurs virtuels Bande passante réseau attendue (Mbit/s) Requêtes GET par seconde sans SSL (taille de valeur de 1 Ko) Requêtes GET par seconde avec SSL (taille de valeur de 1 Ko)
E10 12 Go 4 4 000 300 000 207 000
E20 25 Go 4 4 000 680 000 480 000
E50 50 Go 8 8,000 1 200 000 900 000
E100 100 Go 16 10 000 1 700 000 1 650 000
F300 384 Go 8 3 200 500 000 390 000
F700 715 Go 16 6 400 500 000 370 000
F1500 1 455 Go 32 12 800 530 000 390 000
Stratégie de cluster OSS
Instance Taille Processeurs virtuels Bande passante réseau attendue (Mbit/s) Requêtes GET par seconde sans SSL (taille de valeur de 1 Ko) Requêtes GET par seconde avec SSL (taille de valeur de 1 Ko)
E10 12 Go 4 4 000 1 400 000 1 000 000
E20 25 Go 4 4 000 1 200 000 900 000
E50 50 Go 8 8,000 2 300 000 1 700 000
E100 100 Go 16 10 000 3 000 000 2 500 000
F300 384 Go 8 3 200 1 500 000 1 200 000
F700 715 Go 16 6 400 1 600 000 1 200 000
F1500 1 455 Go 32 12 800 1 600 000 1 110 000

Niveaux Enterprise et Enterprise Flash – Avec scale-out

En plus d’effectuer un scale-up en passant à une plus grande taille de cache, vous pouvez améliorer les performances en effectuant un scale-out. Dans les niveaux Enterprise, le scale-out est appelé augmentation de la capacité de l’instance de cache. Par défaut, une instance de cache a une capacité de deux : un nœud principal et un nœud réplica. Une instance de cache Enterprise avec une capacité de quatre indique que l’instance a été mise à l’échelle d’un facteur de deux. Le scale-out permet d’accéder à davantage de mémoire et de processeurs virtuels. Pour plus d’informations sur le nombre de processeurs virtuels utilisés par le processus Redis principal à chaque taille et capacité de cache, consultez Configuration du partitionnement. Le scale-out est plus efficace lors de l’utilisation de la stratégie de cluster OSS.

Les tableaux suivants montrent les demandes GET par seconde à différentes capacités, à l’aide de SSL et d’une taille de valeur de 1 ko.

Scale-out – Stratégie de cluster Enterprise
Instance Capacité 2 Capacité 4 Capacité 6
E10 200 000 830 000 930 000
E20 480 000 710 000 950 000
E50 900 000 1 110 000 1 200 000
E100 1 600 000 1 120 000 1 200 000
Instance Capacité 3 Capacité 9
F300 390 000 640 000
F700 370 000 610 000
F1500 390 000 670 000
Scale-out – Stratégie de cluster OSS
Instance Capacité 2 Capacité 4 Capacité 6
E10 1 000 000 1 900 000 2 500 000
E20 900 000 1 700 000 2 300 000
E50 1 700 000 3 000 000 3 900 000
E100 2 500 000 4 400 000 4 900 000
Instance Capacité 3 Capacité 9
F300 1 200 000 2 600 000
F700 1 200 000 2 600 000
F1500 1 100 000 2 800 000

Étapes suivantes