Benchmarking der Leistung eines Redis-Servers unter Ubuntu 18.04

Einführung

Benchmarking ist eine wichtige Methode zur Analyse der Gesamtleistung von Datenbankservern. Es ist hilfreich, um Engpässe und Verbesserungsmöglichkeiten in diesen Systemen zu identifizieren.

Redis ist ein speicherinterner Datenspeicher, der als Datenbank-, Cache- und Nachrichtenbroker verwendet werden kann. Es unterstützt einfache bis komplexe Datenstrukturen, darunter Hashes, Strings, sortierte Mengen, Bitmaps und Geodaten. In diesem Handbuch wird gezeigt, wie Sie die Leistung eines Redis-Servers unter Ubuntu 18.04 mit verschiedenen Tools und Methoden messen können.

Voraussetzungen

Um diesem Handbuch zu folgen, benötigen Sie:

[.note] #Note: Die in diesem Lernprogramm gezeigten Befehle wurden auf einem dedizierten Redis-Server ausgeführt, der auf einem 4 GB DigitalOcean Droplet ausgeführt wird.
#

Verwenden des Tools "Includedredis-benchmark"

Redis wird mit einem Benchmark-Tool namensredis-benchmark geliefert. Mit diesem Programm kann eine beliebige Anzahl von Clients simuliert werden, die gleichzeitig eine Verbindung herstellen und Aktionen auf dem Server ausführen. Dabei wird gemessen, wie lange es dauert, bis die Anforderungen abgeschlossen sind. Die resultierenden Daten geben Ihnen eine Vorstellung von der durchschnittlichen Anzahl von Anforderungen, die Ihr Redis-Server pro Sekunde verarbeiten kann.

In der folgenden Liste sind einige der allgemeinen Befehlsoptionen aufgeführt, die mitredis-benchmark verwendet werden:

  • -h: Redis-Host. Standard ist127.0.0.1.

  • -p: Redis-Port. Standard ist6379.

  • -a: Wenn Ihr Server eine Authentifizierung erfordert, können Sie diese Option verwenden, um das Kennwort anzugeben.

  • -c: Anzahl der zu simulierenden Clients (Parallelverbindungen). Der Standardwert ist 50.

  • -n: Wie viele Anfragen müssen gestellt werden? Die Standardeinstellung ist 100000.

  • -d: Datengröße fürSET undGET Werte, gemessen in Bytes. Standard ist 3.

  • -t: Führen Sie nur eine Teilmenge der Tests aus. Beispielsweise können Sie-t get,set verwenden, um die Leistung der BefehleGET undSET zu vergleichen.

  • -P: Verwenden Sie Pipelining zur Leistungsverbesserung.

  • -q: Ruhiger Modus, zeigt nur die durchschnittlichen Informationen vonrequests per secondan.

Wenn Sie beispielsweise die durchschnittliche Anzahl von Anforderungen pro Sekunde überprüfen möchten, die Ihr lokaler Redis-Server verarbeiten kann, können Sie Folgendes verwenden:

redis-benchmark -q

Sie erhalten eine ähnliche Ausgabe, jedoch mit unterschiedlichen Zahlen:

OutputPING_INLINE: 85178.88 requests per second
PING_BULK: 83056.48 requests per second
SET: 72202.16 requests per second
GET: 94607.38 requests per second
INCR: 84961.77 requests per second
LPUSH: 78988.94 requests per second
RPUSH: 88652.48 requests per second
LPOP: 87950.75 requests per second
RPOP: 80971.66 requests per second
SADD: 80192.46 requests per second
HSET: 84317.03 requests per second
SPOP: 78125.00 requests per second
LPUSH (needed to benchmark LRANGE): 84175.09 requests per second
LRANGE_100 (first 100 elements): 52383.45 requests per second
LRANGE_300 (first 300 elements): 21547.08 requests per second
LRANGE_500 (first 450 elements): 14471.78 requests per second
LRANGE_600 (first 600 elements): 9383.50 requests per second
MSET (10 keys): 71225.07 requests per second

Sie können die Tests auch mit dem Parameter-tauf eine Teilmenge von Befehlen Ihrer Wahl beschränken. Der folgende Befehl zeigt nur die Durchschnittswerte für die BefehleGET undSET an:

redis-benchmark -t set,get -q
OutputSET: 76687.12 requests per second
GET: 82576.38 requests per second

Die Standardoptionen verwenden 50 parallele Verbindungen, um 100000 Anforderungen an den Redis-Server zu erstellen. Wenn Sie die Anzahl der Parallelverbindungen erhöhen möchten, um eine Nutzungsspitze zu simulieren, können Sie die Option-cdafür verwenden:

redis-benchmark -t set,get -q -c 1000

Da dies 1000 gleichzeitige Verbindungen anstelle der Standard-50 verwendet, sollten Sie mit einem Leistungsabfall rechnen:

OutputSET: 69444.45 requests per second
GET: 70821.53 requests per second

Wenn Sie detaillierte Informationen in der Ausgabe wünschen, können Sie die Option-q entfernen. Der folgende Befehl verwendet 100 parallele Verbindungen, um 1000000 SET-Anforderungen auf dem Server auszuführen:

redis-benchmark -t set -c 100 -n 1000000

Sie erhalten eine Ausgabe ähnlich der folgenden:

Output====== SET ======
  1000000 requests completed in 11.29 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

95.22% <= 1 milliseconds
98.97% <= 2 milliseconds
99.86% <= 3 milliseconds
99.95% <= 4 milliseconds
99.99% <= 5 milliseconds
99.99% <= 6 milliseconds
100.00% <= 7 milliseconds
100.00% <= 8 milliseconds
100.00% <= 8 milliseconds
88605.35 requests per second

Die Standardeinstellungen verwenden 3 Byte für Schlüsselwerte. Sie können dies mit der Option-d ändern. Der folgende Befehl vergleicht die BefehleGET undSET mit 1-MB-Schlüsselwerten:

redis-benchmark -t set,get -d 1000000 -n 1000 -q

Da der Server diesmal mit einer viel größeren Nutzlast arbeitet, ist mit einer erheblichen Verringerung der Leistung zu rechnen:

OutputSET: 1642.04 requests per second
GET: 822.37 requests per second

Es ist wichtig zu wissen, dass diese Zahlen zwar eine schnelle Möglichkeit zur Bewertung der Leistung einer Redis-Instanz darstellen, jedoch nicht den maximalen Durchsatz darstellen, den eine Redis-Instanz aufrechterhalten kann. Durch die Verwendung vonpipelining können Anwendungen mehrere Befehle gleichzeitig senden, um die Anzahl der Anforderungen pro Sekunde zu verbessern, die der Server verarbeiten kann. Mitredis-benchmark können Sie die Option-P verwenden, um reale Anwendungen zu simulieren, die diese Redis-Funktion verwenden.

Um den Unterschied zu vergleichen, führen Sie zuerst den Befehlredis-benchmark mit Standardwerten und ohne Pipelining für die TestsGET undSET aus:

redis-benchmark -t get,set -q
OutputSET: 86281.27 requests per second
GET: 89847.26 requests per second

Der nächste Befehl führt dieselben Tests aus, fügt jedoch 8 Befehle zusammen:

redis-benchmark -t get,set -q -P 8
OutputSET: 653594.81 requests per second
GET: 793650.75 requests per second

Wie Sie an der Ausgabe sehen können, ergibt sich durch die Verwendung von Pipelining eine erhebliche Leistungsverbesserung.

Überprüfen der Latenz mitredis-cli

Wenn Sie die durchschnittliche Zeit messen möchten, die eine Anforderung zum Empfangen einer Antwort benötigt, können Sie den Redis-Client verwenden, um die durchschnittliche Server-Latenz zu ermitteln. Im Kontext von Redis ist die Latenz ein Maß dafür, wie lange einping-Befehl benötigt, um eine Antwort vom Server zu erhalten.

Mit dem folgenden Befehl werden die Echtzeit-Latenzstatistiken für Ihren Redis-Server angezeigt:

redis-cli --latency

Sie erhalten eine ähnliche Ausgabe mit einer zunehmenden Anzahl von Samples und einer variablen durchschnittlichen Latenz:

Outputmin: 0, max: 1, avg: 0.18 (970 samples)

Dieser Befehl wird auf unbestimmte Zeit ausgeführt. Sie können es mitCTRL+C stoppen.

Um die Latenz über einen bestimmten Zeitraum zu überwachen, können Sie Folgendes verwenden:

redis-cli --latency-history

Dadurch werden Latenzmittelwerte über einen bestimmten Zeitraum hinweg mit einem konfigurierbaren Intervall aufgezeichnet, das standardmäßig auf 15 Sekunden festgelegt ist. Sie erhalten eine Ausgabe ähnlich der folgenden:

Outputmin: 0, max: 1, avg: 0.18 (1449 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.16 (1449 samples) -- 15.00 seconds range
min: 0, max: 1, avg: 0.17 (1449 samples) -- 15.00 seconds range
min: 0, max: 1, avg: 0.17 (1444 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.17 (1446 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.17 (1449 samples) -- 15.00 seconds range
min: 0, max: 1, avg: 0.16 (1444 samples) -- 15.00 seconds range
min: 0, max: 1, avg: 0.17 (1445 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.16 (1445 samples) -- 15.01 seconds range
...

Da der Redis-Server in unserem Beispiel im Leerlauf ist, gibt es keine großen Unterschiede zwischen den Latenzzeitbeispielen. Wenn Sie jedoch eine Nutzungsspitze haben, sollte sich dies in einer Zunahme der Latenz in den Ergebnissen niederschlagen.

Wenn Sie nur die Latenz vonsystemmessen möchten, können Sie dafür--intrinsic-latency verwenden. Die inhärente Latenz hängt von der Umgebung ab und hängt von Faktoren wie Hardware, Kernel, Servernachbarn und anderen Faktoren ab, die nicht von Redis gesteuert werden.

Sie können die intrinsische Latenz als Basis für Ihre gesamte Redis-Leistung betrachten. Der folgende Befehl überprüft die systeminterne Latenz und führt einen Test für 30 Sekunden durch:

redis-cli --intrinsic-latency 30

Sie sollten eine Ausgabe ähnlich der folgenden erhalten:

Output…

498723744 total runs (avg latency: 0.0602 microseconds / 60.15 nanoseconds per run).
Worst run took 22975x longer than the average latency.

Der Vergleich beider Latenztests kann hilfreich sein, um Hardware- oder Systemengpässe zu identifizieren, die die Leistung Ihres Redis-Servers beeinträchtigen könnten. In Anbetracht der Gesamtlatenz für eine Anforderung an unseren Beispielserver, die durchschnittlich 0,18 Mikrosekunden beträgt, bedeutet eine intrinsische Latenz von 0,06 Mikrosekunden, dass ein Drittel der gesamten Anforderungszeit vom System für Prozesse aufgewendet wird, die nicht von Redis gesteuert werden.

Verwenden des Memtier Benchmark-Tools

Memtier ist ein Benchmark-Tool mit hohem Durchsatz für Redis undMemcached, das von Redis Labs erstellt wurde. Obwohl Memtierredis-benchmark in verschiedenen Aspekten sehr ähnlich ist, verfügt es über verschiedene Konfigurationsoptionen, die optimiert werden können, um die erwartete Last auf Ihrem Redis-Server besser zu emulieren, und bietet darüber hinaus Clusterunterstützung.

Um Memtier auf Ihrem Server zu installieren, müssen Sie die Software aus dem Quellcode kompilieren. Installieren Sie zunächst die zum Kompilieren des Codes erforderlichen Abhängigkeiten:

sudo apt-get install build-essential autoconf automake libpcre3-dev libevent-dev pkg-config zlib1g-dev

Wechseln Sie als Nächstes in Ihr Home-Verzeichnis und klonen Sie das Projektmemtier_benchmarkvonGithub repository:

cd
git clone https://github.com/RedisLabs/memtier_benchmark.git

Navigieren Sie zum Projektverzeichnis und führen Sie den Befehlautoreconf aus, um die Anwendungskonfigurationsskripts zu generieren:

cd memtier_benchmark
autoreconf -ivf

Führen Sie das Skriptconfigureaus, um die zum Kompilieren erforderlichen Anwendungsartefakte zu generieren:

./configure

Führen Sie nunmake aus, um die Anwendung zu kompilieren:

make

Sobald der Build abgeschlossen ist, können Sie die ausführbare Datei testen mit:

./memtier_benchmark --version

Dadurch erhalten Sie die folgende Ausgabe:

Outputmemtier_benchmark 1.2.17
Copyright (C) 2011-2017 Redis Labs Ltd.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License .
There is NO WARRANTY, to the extent permitted by law.

Die folgende Liste enthält einige der am häufigsten mit dem Befehlmemtier_benchmark verwendeten Optionen:

  • -s: Serverhost. Standard istlocalhost.

  • -p: Server-Port. Standard ist6379.

  • -a: Authentifizieren Sie Anforderungen mit dem angegebenen Kennwort.

  • -n: Anzahl der Anforderungen pro Client (Standard ist 10000).

  • -c: Anzahl der Clients (Standard ist 50).

  • -t: Anzahl der Threads (Standard ist 4).

  • --pipeline: Pipelining aktivieren.

  • --ratio: Verhältnis zwischenSET undGET Befehlen, Standard ist 1:10.

  • --hide-histogram: Blendet detaillierte Ausgabeinformationen aus.

Die meisten dieser Optionen sind den inredis-benchmark vorhandenen Optionen sehr ähnlich, aber Memtier testet die Leistung auf andere Weise. Um gängige reale Umgebungen besser zu simulieren, wird der vonmemtier_benchmark durchgeführte Standard-Benchmark nur fürGET- undSET-Anforderungen in einem Verhältnis von 1 zu 10 getestet. Mit 10 GET-Operationen für jede SET-Operation im Test ist diese Anordnung repräsentativer für eine allgemeine Webanwendung, die Redis als Datenbank oder Cache verwendet. Sie können den Verhältniswert mit der Option--ratio einstellen.

Der folgende Befehl führtmemtier_benchmark mit Standardeinstellungen aus und stellt nur allgemeine Ausgabeinformationen bereit:

./memtier_benchmark --hide-histogram

[.Hinweis]##

Note: Wenn Sie Ihren Redis-Server so konfiguriert haben, dass eine Authentifizierung erforderlich ist, sollten Sie die Option-a zusammen mit Ihrem Redis-Kennwort für den Befehlmemtier_benchmark angeben:

./memtier_benchmark --hide-histogram -a your_redis_password

Es wird eine Ausgabe ähnlich der folgenden angezeigt:

Output...

4         Threads
50        Connections per thread
10000     Requests per client


ALL STATS
=========================================================================
Type         Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
-------------------------------------------------------------------------
Sets         8258.50          ---          ---      2.19800       636.05
Gets        82494.28     41483.10     41011.18      2.19800      4590.88
Waits           0.00          ---          ---      0.00000          ---
Totals      90752.78     41483.10     41011.18      2.19800      5226.93

Gemäß diesem Lauf vonmemtier_benchmark kann unser Redis-Server ungefähr 90.000 Operationen pro Sekunde in einem Verhältnis von 1:10SET /GET ausführen.

Es ist wichtig zu beachten, dass jedes Benchmark-Tool seinen eigenen Algorithmus für Leistungstests und Datenpräsentation hat. Aus diesem Grund ist es normal, dass auf demselben Server leicht unterschiedliche Ergebnisse erzielt werden, auch wenn ähnliche Einstellungen verwendet werden.

Fazit

In diesem Handbuch haben wir gezeigt, wie Benchmark-Tests auf einem Redis-Server mit zwei unterschiedlichen Tools durchgeführt werden: dem enthaltenen Toolredis-benchmark und dem von Redis Labs entwickelten Toolmemtier_benchmark. Wir haben auch gesehen, wie die Serverlatenz mitredis-cli überprüft wird. Basierend auf den Daten aus diesen Tests haben Sie ein besseres Verständnis dafür, was Sie von Ihrem Redis-Server in Bezug auf die Leistung erwarten und was die Engpässe Ihres aktuellen Setups sind.