Leistungstests

  • Artikel

Das Testen der Leistung einer Redis-Instanz kann eine komplizierte Aufgabe sein. Die Leistung einer Redis-Instanz kann abhängig von Parametern wie der Anzahl der Clients, der Größe der Datenwerte und ob Pipelines verwendet werden, variieren. Es kann auch ein Kompromiss zwischen der Optimierung des Durchsatzes oder der Latenz erforderlich sein.

Glücklicherweise gibt es mehrere Tools, die das Benchmarking von Redis vereinfachen. Zwei der beliebtesten Tools sind redis-benchmark und memtier-benchmark. Dieser Artikel konzentriert sich auf „redis-benchmark“.

Verwenden des Hilfsprogramms „redis-benchmark“

  1. Installieren Sie Open Source Redis Server auf einer Client-VM, die Sie zum Testen verwenden können. Das Hilfsprogramm „redis-benchmark“ ist in die Open Source Redis-Distribution integriert. Anweisungen zum Installieren des Open-Source-Images finden Sie in der Redis-Dokumentation.

  2. Die für Tests verwendete Client-VM sollte sich in derselben Region befinden wie Ihre Azure Cache for Redis-Instanz.

  3. Stellen Sie sicher, dass die verwendete Client-VM über mindestens so viel Computeleistung und Bandbreite wie die getestete Cache-Instanz verfügt.

  4. Konfigurieren Sie Ihre Netzwerkisolations- und Firewalleinstellungen so, dass sichergestellt ist, dass die Client-VM auf Ihre Azure Cache for Redis-Instanz zugreifen kann.

  5. Wenn Sie TLS/SSL mit Ihrer Cache-Instanz verwenden, müssen Sie Ihrem „redis-benchmark“-Befehl den Parameter --tls hinzufügen oder einen Proxy wie stunnel verwenden.

  6. Redis-benchmark verwendet standardmäßig Port 6379 verwendet. Verwenden Sie den Parameter -p, um diese Einstellung zu überschreiben. Sie müssen -p verwenden, wenn Sie SSL/TLS (Port 6380) oder die Enterprise-Dienstebene (Port 10000) verwenden.

  7. Wenn Sie eine Azure Cache for Redis-Instanz verwenden, die Clustering verwendet, müssen Sie Ihrem redis-benchmark-Befehl den Parameter --cluster hinzufügen. Caches der Dienstebene „Enterprise“, die die Enterprise-Clusteringrichtlinie verwenden, können als nicht gruppierte Caches behandelt werden und benötigen diese Einstellung nicht.

  8. Starten Sie redis-benchmark über die CLI oder die Shell des virtuellen Computers. Anweisungen zum Konfigurieren und Ausführen des Tools finden Sie in der „redis-benchmark“-Dokumentation und in den Abschnitten mit „redis-benchmark“-Beispielen.

Benchmarkingempfehlungen

  • Keinesfalls sollten Sie die Leistung Ihres Caches nur unter stabilen Bedingungen testen. Testen Sie außerdem unter Failoverbedingungen, und messen Sie währenddessen die CPU-/Serverauslastung Ihres Cache. Sie können ein Failover auslösen, indem Sie den primären Knoten neu starten. Durch Tests unter Failoverbedingungen können Sie den Durchsatz und die Latenz Ihrer Anwendung unter Failoverbedingungen ermitteln. Ein Failover kann im Rahmen eines Updates oder eines ungeplanten Ereignisses erfolgen. Idealerweise sollte die CPU-/Serverauslastungsspitze selbst während eines Failovers nicht mehr als 80 % betragen, da dies Auswirkungen auf die Leistung haben kann.

  • Erwägen Sie die Verwendung von Azure Cache for Redis-Instanzen der Dienstebenen „Enterprise“ und „Premium“. Diese Cachegrößen verfügen über eine bessere Netzwerklatenz und einen höheren Durchsatz, weil sie auf besserer Hardware ausgeführt werden.

  • Die Enterprise-Dienstebene weist im Allgemeinen die beste Leistung auf, da Redis Enterprise dem Redis-Kernprozess ermöglicht, mehrere vCPUs zu verwenden. Dienstebenen, die auf Open Source Redis basieren, z. B. „Standard“ und „Premium“, können nur eine vCPU für den Redis-Prozess pro Shard verwenden.

  • Das Benchmarking der Dienstebene „Enterprise Flash“ kann sich schwierig gestalten, da einige Schlüssel auf DRAM gespeichert werden, während einige auf einem NVMe-Flashdatenträger gespeichert werden. Die Schlüssel im DRAM-Benchmark sind fast so schnell wie eine Instanz der Dienstebene „Enterprise“, aber die Schlüssel auf dem NVMe-Flashdatenträger sind langsamer. Da die Dienstebene „Enterprise Flash“ die am häufigsten verwendeten Schlüssel intelligent in DRAM platziert, stellen Sie sicher, dass Ihre Benchmarkkonfiguration der tatsächlichen, von Ihnen erwarteten Nutzung entspricht. Erwägen Sie, den Parameter -r zu verwenden, um zu randomisieren, auf welche Schlüssel zugegriffen wird.

  • Die Verwendung von TLS/SSL verringert die Durchsatzleistung, was sich in den Beispielbenchmarkdaten in den folgenden Tabellen sehen lässt.

  • Obwohl ein Redis-Server mit Einzelthreads arbeitet, verbessert das Hochskalieren tendenziell die Durchsatzleistung. Systemprozesse können die zusätzlichen vCPUs verwenden, anstatt die vCPU gemeinsam zu nuten, die vom Redis-Prozess verwendet wird. Das Hochskalieren ist besonders auf den Dienstebenen „Enterprise“ und „Enterprise Flash“ hilfreich, da Redis Enterprise nicht auf einen einzelnen Thread beschränkt ist. Weitere Informationen finden Sie unter Bewährte Methoden für die Dienstebene „Enterprise“.

  • Auf der Dienstebene „Premium“ wird in der Regel Clustering vor dem Aufskalieren empfohlen. Das Clustering ermöglicht es dem Redis-Server, mehr vCPUs durch Sharding von Daten zu verwenden. Der Durchsatz sollte beim Hinzufügen von Shards in diesem Fall etwa linear steigen.

Beispiele für Redis-Benchmark

Testvorbereitung: Bereiten Sie die Cache-Instanz mit Daten vor, die zum Testen von Latenz und Durchsatz erforderlich sind:

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

So testen Sie die Latenz: Testen von GET-Anforderungen anhand von 1 KB Nutzdaten:

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

So testen Sie den Durchsatz: GET-Anforderungen in Pipeline mit 1 KB Nutzdaten:

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

So testen Sie den Durchsatz eines Caches der Dienstebene „Basic“, „Standard“ oder „Premium“ mithilfe von TLS: GET-Anforderungen über Pipelines mit Nutzlast der Größe 1k:

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

So testen Sie den Durchsatz eines Enterprise- oder Enterprise Flash-Caches ohne TLS im OSS-Clustermodus: GET-Anforderungen über Pipelines mit Nutzlast der Größe 1k:

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

Beispieldaten zu Leistungsbenchmarks

Die folgenden Tabellen zeigen die maximalen Durchsatzwerte, die während der Tests verschiedener Größen von Standard-, Premium-, Enterprise- und Enterprise Flash-Caches beobachtet wurden. Wir haben redis-benchmark von einer IaaS-Azure-VM aus auf den Azure Cache for Redis-Endpunkt angewendet. Die Durchsatzzahlen gelten nur für GET-Befehle. In der Regel weisen SET-Befehle einen niedrigeren Durchsatz auf. Diese Zahlen sind für den Durchsatz optimiert. Der reale Durchsatz unter akzeptablen Latenzbedingungen kann geringer ausfallen.

Die folgende Konfiguration wurde für das Benchmarking des Durchsatzes für die Tarife „Basic“, „Standard“ und „Premium“ verwendet:

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

Achtung

Diese Werte werden nicht garantiert, und es gibt keine SLA für diese Werte. Es wird dringend empfohlen, eigene Leistungstests durchzuführen, um die richtige Cachegröße für Ihre Anwendung zu ermitteln. Diese Zahlen können sich ändern, da wir in regelmäßigen Abständen neuere Ergebnisse veröffentlichen.

Wichtig

Microsoft aktualisiert regelmäßig die zugrunde liegende VM, die in Cacheinstanzen verwendet wird. Dadurch können die Leistungsmerkmale von Cache zu Cache und von Region zu Region geändert werden. Die Beispiel-Benchmarkwerte auf dieser Seite spiegeln Cachehardware der älteren Generation in einer einzelnen Region wider. Möglicherweise sehen Sie in der Praxis bessere oder andere Ergebnisse.

Standard-Tarif

Instanz Size vCPUs Erwartete Netzwerkbandbreite (MBit/s) GET-Anforderungen pro Sekunde ohne SSL (1-KB-Wertgröße) GET-Anforderungen pro Sekunde mit SSL (1-KB-Wertgröße)
C0 250 MB Shared 100 15.000 7\.500
C1 1 GB 1 500 38.000 20.720
C2 2,5 GB 2 500 41.000 37.000
C3 6 GB 4 1000 100.000 90.000
C4 13 GB 2 500 60.000 55.000
C5 26 GB 4 1\.000 102.000 93.000
C6 53 GB 8 2\.000 126.000 120.000

Premium-Tarif

Instanz Size vCPUs Erwartete Netzwerkbandbreite (MBit/s) GET-Anforderungen pro Sekunde ohne SSL (1-KB-Wertgröße) GET-Anforderungen pro Sekunde mit SSL (1-KB-Wertgröße)
P1 6 GB 2 1\.500 180.000 172.000
P2 13 GB 4 3,000 350.000 341.000
P3 26 GB 4 3,000 350.000 341.000
P4 53 GB 8 6\.000 400.000 373.000
P5 120 GB 32 6\.000 400.000 373.000

Wichtig

P5-Instanzen in den Regionen China Ost und China Nord verwenden 20 Kerne, nicht 32 Kerne.

Enterprise & Enterprise Flash-Ebenen

Die Dienstebenen „Enterprise“ und „Enterprise Flash“ bieten eine Auswahl an Clusterrichtlinien: Enterprise und OSS. Die Enterprise-Clusterrichtlinie ist eine einfachere Konfiguration, für die der Client kein Clustering unterstützen muss. Die OSS-Clusterrichtlinie hingegen verwendet das Redis-Clusterprotokoll, um höhere Durchsätze zu unterstützen. In den meisten Fällen wird die Verwendung der OSS-Clusterrichtlinie empfohlen. Weitere Informationen finden Sie unter Clustering auf Enterprise. Benchmarks für beide Clusterrichtlinien sind in den folgenden Tabellen aufgeführt.

Die folgende Konfiguration wurde für das Benchmarking des Durchsatzes für die Tarife „Enterprise“ und „Enterprise Flash“ verwendet:

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

Hinweis

Diese Konfiguration ist nahezu identisch mit der Konfiguration, die für das Benchmarking für die Tarife „Basic“, „Standard“ und „Premium“ verwendet wird. Die vorherige Konfiguration hat jedoch die höhere Computeleistung der Enterprise-Tarife nicht vollständig genutzt. Dieser Konfiguration wurden zusätzliche Anforderungen und Threads hinzugefügt, um die volle Leistung zu demonstrieren.

Enterprise-Clusterrichtlinie

Instanz Size vCPUs Erwartete Netzwerkbandbreite (MBit/s) GET-Anforderungen pro Sekunde ohne SSL (1-KB-Wertgröße) GET-Anforderungen pro Sekunde mit SSL (1-KB-Wertgröße)
E10 12 GB 4 4\.000 300.000 207,000
E20 25 GB 4 4\.000 680.000 480,000
E50 50 GB 8 8\.000 1\.200.000 900,000
E100 100 GB 16 10.000 1,700,000 1,650,000
F300 384 GB 8 3\.200 500.000 390.000
F700 715 GB 16 6\.400 500.000 370,000
F1500 1455 GB 32 12.800 530.000 390.000

OSS-Clusterrichtlinie

Instanz Size vCPUs Erwartete Netzwerkbandbreite (MBit/s) GET-Anforderungen pro Sekunde ohne SSL (1-KB-Wertgröße) GET-Anforderungen pro Sekunde mit SSL (1-KB-Wertgröße)
E10 12 GB 4 4\.000 1.400.000 1\.000.000
E20 25 GB 4 4\.000 1\.200.000 900,000
E50 50 GB 8 8\.000 2,300,000 1,700,000
E100 100 GB 16 10.000 3,000,000 2,500,000
F300 384 GB 8 3\.200 1\.500.000 1\.200.000
F700 715 GB 16 6\.400 1\.600.000 1\.200.000
F1500 1455 GB 32 12.800 1\.600.000 1,110,000

Enterprise & Enterprise Flash Tiers – Skaliert

Zusätzlich zum Hochskalieren durch die Umstellung auf eine größere Cachegröße können Sie die Leistung steigern, indem Sie aufskalieren. In den Enterprise-Dienstebenen wird das Aufskalieren als Erhöhen der Kapazität der Cache-Instanz bezeichnet. Eine Cache-Instanz hat standardmäßig eine Kapazität von zwei, d. h. einen primären Knoten und einen Replikatknoten. Eine Enterprise-Cache-Instanz mit einer Kapazität von vier zeigt an, dass die Instanz um den Faktor zwei aufskaliert wurde. Aufskalieren bietet Zugriff auf mehr Arbeitsspeicher und vCPUs. Details dazu, wie viele vCPUs vom Redis-Kernprozess bei der jeweiligen Cachegröße und -kapazität verwendet werden, finden Sie auf der Seite mit den bewährten Methoden für Enterprise-Dienstebenen. Das Aufskalieren ist am effektivsten, wenn die OSS-Clusterrichtlinie verwendet wird.

Die folgenden Tabellen zeigen die GET-Anforderungen pro Sekunde bei unterschiedlichen Kapazitäten unter Verwendung von SSL und einer Wertgröße von 1 KB.

Aufskalieren – Enterprise-Clusterrichtlinie

Instanz Kapazität 2 Kapazität 4 Kapazität 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
Instanz Kapazität 3 Kapazität 9
F300 390.000 640,000
F700 370,000 610.000
F1500 390.000 670,000

Aufskalieren – OSS-Clusterrichtlinie

Instanz Kapazität 2 Kapazität 4 Kapazität 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
Instanz Kapazität 3 Kapazität 9
F300 1\.200.000 2,600,000
F700 1\.200.000 2,600,000
F1500 1.100.000 2,800,000

Nächste Schritte