Anmerkung
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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“
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.
Der für den Test verwendete virtuelle Clientcomputer (Virtual Machine, VM) muss sich in derselben Region befinden wie Ihre Azure Managed Redis-Instanz (AMR).
Stellen Sie sicher, dass die verwendete Client-VM über mindestens so viel Computeleistung und Bandbreite wie die getestete Cache-Instanz verfügt.
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.
Wenn Sie für Ihre Cache-Instanz TLS/SSL verwenden, müssen Sie Ihrem „memtier_benchmark“-Befehl die Parameter
--tlsund--tls-skip-verifyhinzufügen.memtier_benchmarkverwendet standardmäßig Port 6379 verwendet. Verwenden Sie den Parameter-p 10000, um diese Einstellung zu überschreiben, da AMR stattdessen den Port 10000 verwendet.Für alle Azure Managed Redis-Instanzen, die die OSS-Clusterrichtlinie verwenden, müssen Sie den Parameter
--cluster-modezu 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.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 jede Größe und Ebene verfügbaren vCPUs finden Sie unter Stufen 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 verwenden oder wenn Sie die Enterprise-Clusterrichtlinie verwenden.
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 folgende Tabelle zeigt den optimalen Durchsatz, den wir beim Testen verschiedener Größen von Azure Managed Redis-Instanzen mit einer Arbeitsauslastung aller Lesebefehle und 1 KB-Nutzlast beobachtet haben. Die Workload ist für alle SKUs gleich, mit Ausnahme der Verbindungsanzahl (d. a. unterschiedliche Thread- und Clientanzahl, wie für memtier_benchmark erforderlich). Die Verbindungsanzahl wird pro SKU ausgewählt, um die Azure Managed Redis-Instanz optimal zu nutzen. 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.
Vorsicht
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. Die Leistung kann aus verschiedenen Gründen variieren, z. B. unterschiedliche Verbindungsanzahl, Nutzlastgröße, ausgeführte Befehle usw.
Von Bedeutung
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 eine bestimmte Cachehardware der Generation in einer einzelnen Region wider. Möglicherweise werden in der Praxis unterschiedliche Ergebnisse angezeigt, insbesondere bei Netzwerkbandbreite.
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. Es wird empfohlen, osS-Clusterrichtlinien in den meisten Fällen zu verwenden, insbesondere, wenn Sie eine hohe Leistung erfordern. Weitere Informationen finden Sie unter Clustering.
| Größe in GB | GET-Anforderungen pro Sekunde für „Speicheroptimiert“ | GET-Anforderungen pro Sekunde für Balanced | GET-Anforderungen pro Sekunde für "Compute Optimized" |
|---|---|---|---|
| 0,5 | - | 120.000 | - |
| 1 | - | 120.000 | - |
| 3 | - | 230.000 | 480.000 |
| 6 | - | 230.000 | 480.000 |
| 12 | 230.000 | 480.000 | 810.000 |
| 24 | 480.000 | 810.000 | 1.600.000 |
| 60 | 810.000 | 1.500.000 | 2\.000.000 |
| 120 | 1.500.000 | 2\.000.000 | 2.900.000 |
In der folgenden Tabelle sind die Anzahl der Verbindungen in Bezug auf die Anzahl der Threads bei memtier_benchmark sowie die Anzahl der Clients aufgeführt, die für die Ermittlung der Durchsatzwerte verwendet wurden. Wie bereits erwähnt, kann das Ändern der Verbindungsanzahl zu einer unterschiedlichen Leistung führen.
| Größe in GB | Clients/Threads/Verbindungsanzahl für Arbeitsspeicheroptimierung | Anzahl der Clients/Threads/Verbindungen für Balanced | Clients/Threads/Verbindungsanzahl für Rechneroptimierung |
|---|---|---|---|
| 0,5 | - | 10/4/40 | - |
| 1 | - | 10/4/40 | - |
| 3 | - | 10/4/40 | 10/8/80 |
| 6 | - | 10/4/40 | 10/8/80 |
| 12 | 10/4/40 | 10/8/80 | 10/16/160 |
| 24 | 10/8/80 | 10/16/160 | 20/16/320 |
| 60 | 10/16/160 | 20/16/320 | 20/32/640 |
| 120 | 20/16/320 | 20/32/640 | 20/64/1.280 |