Freigeben über

Leistungstests für Azure Managed Redis (Vorschau)

  • 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 befasst sich mit „memtier_benchmark“, häufig auch als memtier bezeichnet.

Verwenden des Hilfsprogramms „memtier_benchmark“

  1. Installieren Sie memtier auf virtuellen Clientcomputern (Virtual Machines, VMs), die Sie zum Testen verwenden können. Anweisungen zum Installieren des Open-Source-Images finden Sie in der Memtier-Dokumentation.

  2. Der für den Test verwendete virtuelle Clientcomputer (Virtual Machine, VM) muss sich in derselben Region befinden wie Ihre Azure Managed Redis-Instanz (AMR).

  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 die Einstellungen für Ihre Netzwerkisolation und Ihre VM-Firewall so, dass sichergestellt ist, dass die Client-VM auf Ihre Azure Managed Redis-Instanz zugreifen kann.

  5. Wenn Sie für Ihre Cache-Instanz TLS/SSL verwenden, müssen Sie Ihrem „memtier_benchmark“-Befehl die Parameter --tls und --tls-skip-verify hinzufügen.

  6. memtier_benchmark verwendet standardmäßig Port 6379 verwendet. Verwenden Sie den Parameter -p 10000, um diese Einstellung zu überschreiben, da AMR stattdessen den Port 10000 verwendet.

  7. Für alle Azure Managed Redis-Instanzen, die die OSS-Clusterrichtlinie verwenden, müssen Sie den Parameter --cluster-mode zu Ihrem „memtier“-Befehl hinzufügen. AMR-Instanzen, die die Enterprise-Clusterrichtlinie verwenden, können als nicht gruppierte Caches behandelt werden und benötigen diese Einstellung nicht.

  8. Starten Sie memtier_benchmark über die CLI oder die Shell des virtuellen Computers. Anweisungen zum Konfigurieren und Ausführen des Tools finden Sie in der Memtier-Dokumentation.

Benchmarkingempfehlungen

  • Wenn Sie nicht die benötigte Leistung erzielen, versuchen Sie, auf einen erweiterten Tarif hochzuskalieren. Der Tarif „Ausgewogen“ weist in der Regel doppelt so viele vCPUs auf wie der Tarif „arbeitsspeicheroptimiert“, und der Tarif „Für Compute optimiert“ in der Regel doppelt so viele der Tarif „Ausgeglichen“. Da Azure Managed Redis auf Redis Enterprise und nicht auf Community Redis basiert, kann der Redis-Kernprozess mehrere vCPUs verwenden. Im Ergebnis weisen Instanzen mit mehr vCPUs eine deutlich bessere Durchsatzleistung auf.

  • Durch das Hochskalieren auf größere Arbeitsspeichergrößen werden auch mehr vCPUs hinzugefügt, wodurch die Leistung erhöht wird. Das Hochskalieren auf größere Speichergrößen ist jedoch in der Regel weniger effektiv als die Verwendung eines leistungsfähigeren Tarifs. Eine detaillierte Aufschlüsselung der für die einzelnen Größen und Tarife verfügbaren vCPUs finden Sie unter Tarife und SKUs auf einen Blick.

  • Das Benchmarking des Tarifs „Flash-optimiert“ kann sich schwierig gestalten, da einige Schlüssel in DRAM gespeichert werden, andere dagegen auf einem NVMe-Flashdatenträger. Die Schlüssel im DRAM-Benchmark sind fast so schnell wie andere Azure Managed Redis-Instanzen, die Schlüssel auf dem NVMe-Flashdatenträger sind jedoch langsamer. Da der Tarif „Flash-optimiert“ die am häufigsten verwendeten Schlüssel intelligent im DRAM platziert, müssen Sie sicherstellen, dass Ihre Benchmarkkonfiguration der von Ihnen tatsächlich erwarteten Nutzung entspricht.

  • Die Verwendung von TLS/SSL verringert die Durchsatzleistung, wird jedoch als bewährte Methode für die Produktion dringend empfohlen.

  • Es ist wichtig, zuerst die Redis-Instanz mit Daten zu füllen, bevor das Benchmarking durchgeführt wird. Das Benchmarking mit einem leeren Cache führt zu wesentlich besseren Ergebnissen als in der Praxis.

  • Die Anzahl der verwendeten Verbindungen wirkt sich erheblich auf die Benchmark aus. Durch die Verwendung zu vieler Verbindungen wird die Leistung des Caches beeinträchtigt. Die Verwendung zu weniger Verbindungen zeigt demgegenüber nicht die vollständige Leistung des Caches. Es wird empfohlen, die Anzahl der Verbindungen basierend auf den tatsächlichen Anforderungen Ihrer Anwendung zu konfigurieren. Sie können die Gesamtzahl der benötigten Verbindungen ermitteln, indem Sie die Anzahl der Clients mit der Anzahl der Threads multiplizieren.

  • Die Pipelinekonfiguration wirkt sich erheblich auf die Leistungstests aus. Wenn Sie die Einstellung der Pipeline so festlegen, dass sie größer ist, erhalten Sie mehr Durchsatz, aber schlechtere Latenz. Weitere Informationen finden Sie unter Pipelining.

Beispiele für „memtier_benchmark“

Hinweis

In diesem Beispiel wird das Durchführen eines Benchmarkings für eine für Compute optimierte X3-Instanz mit der OSS-Clusterrichtlinie und TLS gezeigt.

Setup vor dem Test: Bereiten Sie die Cache-Instanz mit Daten vor, die für den Test erforderlich sind. Durch das Laden der Instanz mit Daten wird sichergestellt, dass die Ergebnisse die realen Bedingungen genauer widerspiegeln. Der Parameter {number-of-keys} sollte durch die Größe Ihrer AMR-Instanz und die Größe der einzelnen Schlüssel bestimmt werden. Eine gute Faustregel lautet, die Instanz zu ungefähr 75 Prozent auszufüllen, um einen Puffer zu lassen. Sie können die folgende Formel verwenden: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300). Wenn Sie beispielsweise ein Benchmarking für eine für Compute optimierte X3-Instanz durchführen, verwenden Sie 1.024 Byte-Schlüsselgrößen, wie zuvor gezeigt. Dies impliziert {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300). Das Ergebnis entspricht ungefähr 1.699.396 Schlüsseln.

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

Hinweis

In diesem Beispiel werden die Flags --tls, --tls-skip-verify und --cluster-mode verwendet. Sie benötigen diese nicht, wenn Sie Azure Managed Redis im Nicht-TLS-Modus oder die Enterprise-Clusterrichtlinieverwenden.

So testen Sie den Durchsatz: Dieser Befehl testet GET-Anforderungen in der Pipeline mit 1 K Nutzdaten. Verwenden Sie diesen Befehl, um zu testen, wie viel Lesedurchsatz von Ihrer Cache-Instanz zu erwarten ist. In diesem Beispiel wird davon ausgegangen, dass Sie TLS und die OSS-Clusterrichtlinie verwenden. Der Parameter --key-pattern=R:R stellt sicher, dass Schlüssel zufällig aufgerufen werden, was das Benchmarking realistischer macht. Dieser Test wird fünf Minuten lang ausgeführt.

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

Beispieldaten zu Leistungsbenchmarks

Die folgenden Tabellen zeigen die maximalen Durchsatzwerte, die während der Tests verschiedener Größen von Azure Managed Redis beobachtet wurden. Wir haben memtier_benchmark von einer IaaS-Azure-VM für den Azure Managed Redis-Endpunkt verwendet, wobei wir die „memtier“-Befehle benutzt haben, die im Abschnitt Beispiele für „memtier_benchmark“ gezeigt wurden. Die Durchsatzzahlen gelten nur für GET-Befehle. In der Regel weisen SET-Befehle einen niedrigeren Durchsatz auf. Die reale Leistung variiert je nach Redis-Konfiguration und -Befehlen. Diese Zahlen sind ein Referenzpunkt, keine Garantie.

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. Dies hängt insbesondere von der Netzwerkbandbreite ab.

Azure Managed Redis bietet 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 verwendet hingegen das Redis-Clusterprotokoll, um höheren Durchsatz zu unterstützen. In den meisten Fällen wird die Verwendung der OSS-Clusterrichtlinie empfohlen. Weitere Informationen finden Sie unter Clustering.

Benchmarks für beide Clusterrichtlinien sind in den folgenden Tabellen aufgeführt. Für die OSS-Clusterrichtlinientabelle werden zwei Benchmarkkonfigurationen bereitgestellt:

  • 300 Verbindungen (50 Clients und 6 Threads)
  • 2.500 Verbindungen (50 Clients und 50 Threads)

Die zweiten Benchmarks werden bereitgestellt, da 300 Verbindungen nicht ausreichen, um die volle Leistung der größeren Cache-Instanzen zu demonstrieren.

Im Folgenden finden Sie den Durchsatz in GET-Vorgängen pro Sekunde für 1 kB Nutzdaten für AMR-Instanzen sowie die Anzahl der Clientverbindungen, die für das Benchmarking verwendet wurden. Alle Zahlen wurden für AMR-Instanzen mit SSL-Verbindungen berechnet, und die Netzwerkbandbreite wird in Mbps aufgezeichnet.

OSS-Clusterrichtlinie

Größe in GB vCPU/Netzwerkbandbreite/arbeitsspeicheroptimiert vCPU/Netzwerkbandbreite/Ausgewogen vCPU/Netzwerkbandbreite/Für Compute optimiert
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

Enterprise-Clusterrichtlinie

Größe in GB vCPU/Netzwerkbandbreite/arbeitsspeicheroptimiert vCPU/Netzwerkbandbreite/Ausgewogen vCPU/Netzwerkbandbreite/Für Compute optimiert
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