Fehlerbehebung bei langsamen Redis-Befehlen: Eine Performance-Checkliste

Langsame Redis-Befehle beginnen meist als normale Befehle, deren Annahmen nicht mehr zutreffen. Ein SMEMBERS-Aufruf war harmlos, als das Set 200 Elemente hatte. Eine Dashboard-Abfrage war in Ordnung, als sie 50 Schlüssel lud. Ein Lua-Skript war schnell, bis ein Kunde eine wesentlich größere Datenstruktur erstellte als alle anderen.

Die nützliche Frage ist nicht nur „Welcher Befehl ist langsam?", sondern „Welche Datenstruktur hat diesen Befehl verlangsamt, und warum fordert die Anwendung Redis auf, so viel Arbeit auf einmal zu erledigen?"

Redis-Performance verstehen

Die Leistung von Redis ist aufgrund seiner In-Memory-Natur im Allgemeinen außergewöhnlich. Mehrere Faktoren können jedoch zur Befehls-Latenz beitragen:

Befehls-Komplexität: Bestimmte Befehle sind von Natur aus ressourcenintensiver als andere (z. B. KEYS auf einem großen Datensatz vs. GET).
Datengröße und -struktur: Große Listen, Sets oder sortierte Sets oder komplexe Datenstrukturen können die Leistung von Befehlen beeinträchtigen, die auf ihnen operieren.
Netzwerk-Latenz: Obwohl dies nicht direkt ein Befehlsproblem ist, kann eine hohe Netzwerklatenz zwischen Client und Server dazu führen, dass Befehle langsam erscheinen.
Serverauslastung: Hohe CPU-Auslastung, unzureichender Arbeitsspeicher oder andere Prozesse auf dem Redis-Server können die Leistung beeinträchtigen.
Blockierende Befehle: Bestimmte Operationen können die Redis-Ereignisschleife blockieren und alle nachfolgenden Befehle beeinträchtigen.

Identifizieren langsamer Befehle mit `SLOWLOG`

Der Befehl SLOWLOG ist der integrierte Mechanismus von Redis zum Protokollieren von Befehlen, die eine bestimmte Ausführungszeit überschreiten. Dies ist Ihr primäres Werkzeug, um problematische Befehle proaktiv zu identifizieren.

Wie `SLOWLOG` funktioniert

Redis verwaltet einen Ringpuffer, der Informationen über Befehle speichert, die länger als der konfigurierte Schwellenwert slowlog-log-slower-than (in Mikrosekunden) gedauert haben. Der Standard-Schwellenwert beträgt typischerweise 10 Millisekunden (10000 Mikrosekunden). Wenn dieser Puffer voll ist, werden ältere Einträge verworfen.

Wichtige `SLOWLOG`-Unterbefehle

SLOWLOG GET [count]: Ruft die letzten count Einträge aus dem Slow Log ab. Wenn count weggelassen wird, werden alle Einträge abgerufen.
SLOWLOG LEN: Gibt die aktuelle Länge des Slow Logs zurück (Anzahl der Einträge).
SLOWLOG RESET: Löscht die Slow-Log-Einträge. Verwenden Sie diesen Befehl mit Vorsicht, da er die protokollierten Daten dauerhaft entfernt.

Beispielverwendung von `SLOWLOG`

Angenommen, Sie vermuten, dass einige Befehle zu lange dauern. Sie können das Slow Log wie folgt überprüfen:

# Verbinden Sie sich mit Ihrer Redis-Instanz
redis-cli

# Holen Sie sich die letzten 5 langsamen Befehle
127.0.0.1:6379> SLOWLOG GET 5

Die Ausgabe sieht in etwa so aus:

1) 1) (integer) 18
   2) (integer) 1678886400
   3) (integer) 15000
   4) 1) "KEYS"
      2) "*"

2) 1) (integer) 17
   2) (integer) 1678886390
   3) (integer) 12000
   4) 1) "SMEMBERS"
      2) "my_large_set"

...

Erklärung der Ausgabe:

Eintrags-ID: Eine eindeutige Kennung für den Slow-Log-Eintrag.
Zeitstempel: Der Unix-Zeitstempel, zu dem der Befehl ausgeführt wurde.
Ausführungszeit: Die Dauer (in Mikrosekunden), die der Befehl zur Ausführung benötigte.
Befehl und Argumente: Der Befehl selbst und seine Argumente.

Im obigen Beispiel dauerte KEYS * 15000 Mikrosekunden (15ms) und SMEMBERS my_large_set dauerte 12000 Mikrosekunden (12ms). Diese würden als langsam betrachtet, wenn Ihr slowlog-log-slower-than auf 10000 Mikrosekunden eingestellt ist.

Konfigurieren von `slowlog-log-slower-than`

Sie können den Schwellenwert slowlog-log-slower-than dynamisch mit dem Befehl CONFIG SET ändern:

127.0.0.1:6379> CONFIG SET slowlog-log-slower-than 50000  # Befehle protokollieren, die langsamer als 50ms sind

Um diese Änderung über Redis-Neustarts hinweg dauerhaft zu machen, müssten Sie die Datei redis.conf ändern und den Redis-Server neu starten oder CONFIG REWRITE verwenden, um die Änderungen in der Konfigurationsdatei zu speichern.

Echtzeit-Befehlsüberwachung mit `MONITOR`

Während SLOWLOG eine historische Ansicht bietet, liefert MONITOR einen Echtzeit-Stream aller Befehle, die vom Redis-Server ausgeführt werden. Dies ist unschätzbar wertvoll für das Debugging während einer bestimmten Phase langsamer Leistung oder zum Verständnis von Befehlstrafikmustern.

Wie `MONITOR` funktioniert

Wenn Sie MONITOR aktivieren, sendet Redis eine Antwort an den MONITOR-Client für jeden Befehl, den es empfängt und verarbeitet. Dies kann eine sehr hohe Ausgabemenge erzeugen, insbesondere auf stark ausgelasteten Redis-Instanzen. Daher wird allgemein empfohlen, MONITOR sparsam und nur bei aktivem Debugging einzusetzen.

Beispielverwendung von `MONITOR`

Führen Sie den Befehl MONITOR in einer separaten redis-cli-Sitzung aus:

# Verbinden Sie sich mit Ihrer Redis-Instanz in einem *separaten* Terminal
redis-cli

# Starten Sie die Überwachung
127.0.0.1:6379> MONITOR

Jeder Befehl, der in einer anderen redis-cli-Sitzung oder von Ihrer Anwendung ausgeführt wird, erscheint nun in der MONITOR-Ausgabe. Wenn Sie beispielsweise SET mykey myvalue in einem anderen Client ausführen, sehen Sie:

1678887000.123456 [0 127.0.0.1:54321] "SET" "mykey" "myvalue"

Verwenden von `MONITOR` zum Debugging

Reproduzieren Sie das Problem: Wenn Sie eine Verlangsamung bemerken, starten Sie sofort MONITOR in einer dedizierten redis-cli-Sitzung.
Lösen Sie die langsame Operation aus: Lassen Sie Ihre Anwendung die Aktion ausführen, von der Sie vermuten, dass sie die Verlangsamung verursacht.
Analysieren Sie die Ausgabe: Beobachten Sie die Befehle im MONITOR-Stream. Achten Sie auf:
- Befehle, die lange brauchen, um zu erscheinen (obwohl MONITOR selbst keine Ausführungszeit anzeigt, können Sie diese durch manuelles Timing der Befehle oder Beobachten von Verzögerungen ableiten).
- Ungewöhnliche oder unerwartete Befehle, die ausgeführt werden.
- Ein hohes Volumen an Befehlen, die den Server überlasten könnten.
Stoppen Sie die Überwachung: Drücken Sie Strg+C, um den Befehl MONITOR zu beenden.

Wichtig: Führen Sie MONITOR in einer Produktionsumgebung nicht über längere Zeiträume aus, da dies die Redis-Leistung aufgrund des Overheads des Sendens jedes Befehls an den Client erheblich beeinträchtigen kann.

Häufige Ursachen für langsame Befehle und deren Behebung

Basierend auf den Informationen aus SLOWLOG und MONITOR sind hier die häufigsten Übeltäter und ihre Lösungen:

1. Der Befehl `KEYS`

Problem: Der Befehl KEYS durchläuft den gesamten Keyspace, um Schlüssel zu finden, die einem Muster entsprechen. Bei Datenbanken mit Millionen von Schlüsseln kann dies sehr lange dauern und den Redis-Server blockieren, was sich auf alle anderen Clients auswirkt.
Lösung: Vermeiden Sie KEYS auf großen Produktions-Keyspaces. Verwenden Sie SCAN, wenn Sie eine inkrementelle Schlüsseliteration benötigen. SCAN gibt bei jedem Aufruf eine Teilmenge von Schlüsseln zurück, die einem Muster entsprechen, was die Wahrscheinlichkeit einer langen Blockierung des Servers verringert.
```
  # Anstelle von KEYS user:*
  redis-cli -h <host> -p <port> SCAN 0 MATCH user:* COUNT 100
```
Sie müssen SCAN mehrmals aufrufen, wobei Sie den vom vorherigen Aufruf zurückgegebenen Cursor verwenden, bis der Cursor auf 0 zurückgesetzt wird.

2. Komplexe Skripterstellung (Lua-Skripte)

Problem: Lang laufende oder ineffiziente Lua-Skripte, die über EVAL oder EVALSHA ausgeführt werden, können den Server blockieren. Obwohl Redis Skripte atomar ausführt, kann ein einzelnes langes Skript die Ereignisschleife monopolisieren.
Lösung: Optimieren Sie Ihre Lua-Skripte. Zerlegen Sie komplexe Logik in kleinere, überschaubare Skripte. Analysieren Sie die Skriptleistung. Stellen Sie sicher, dass Schleifen in Skripten effizient sind und korrekt beendet werden. Messen Sie die Leistung Ihrer Skripte, um ihre Ausführungszeit zu verstehen.

3. Operationen auf großen Datenstrukturen

Problem: Befehle wie SMEMBERS auf einem Set mit Millionen von Mitgliedern, LRANGE auf einer sehr langen Liste oder ZRANGE auf einem riesigen sortierten Set können langsam sein.
Lösung: Vermeiden Sie das Abrufen ganzer großer Datenstrukturen. Verwenden Sie stattdessen iterative Befehle oder verarbeiten Sie Daten in Blöcken:
- Sets: Verwenden Sie SSCAN anstelle von SMEMBERS.
- Listen: Verwenden Sie LRANGE mit kleineren start- und stop-Werten, um Daten seitenweise abzurufen.
- Sortierte Sets: Verwenden Sie ZRANGE mit LIMIT oder ZSCAN.

4. Befehle, die eine Schlüsseliteration erfordern (weniger häufig, aber möglich)

Problem: Obwohl weniger häufig, könnten Befehle, die aufgrund ihrer Natur implizit über Schlüssel iterieren, langsam sein, wenn der Keyspace groß ist.
Lösung: Überprüfen Sie die Redis-Befehlsreferenz für den spezifischen Befehl und verstehen Sie seine Komplexität. Erwägen Sie alternative Datenstrukturen oder Ansätze, wenn sich ein bestimmter Befehl als Engpass erweist.

5. Blockierende Befehle (selten in modernem Redis)

Problem: Ältere Redis-Versionen hatten einige Befehle, die den Server blockieren konnten. Die meisten davon wurden behoben oder ersetzt.
Lösung: Stellen Sie sicher, dass Sie eine aktuelle Version von Redis verwenden. Konsultieren Sie die Redis-Dokumentation für bekannte blockierende Operationen, die für Ihre Version spezifisch sind.

Entscheiden Sie zuerst, ob Redis langsam ist oder der Client wartet

Wenn jemand sagt „Redis ist langsam", kann das verschiedene Dinge bedeuten. Der Server verbringt möglicherweise zu viel Zeit mit der Ausführung eines Befehls. Der Client wartet möglicherweise auf das Netzwerk. Ein Verbindungspool ist möglicherweise erschöpft. Ein TLS-Proxy ist möglicherweise überlastet. Eine große Antwort benötigt möglicherweise länger für die Übertragung als der Befehl für die Ausführung.

SLOWLOG zeichnet nur die Befehlsausführungszeit innerhalb von Redis auf. Es enthält nicht die Netzwerkübertragungszeit, die Client-Wartezeit in der Warteschlange oder die Zeit, die für das Warten auf eine Verbindung aus einem Anwendungspool aufgewendet wird. Deshalb beweist ein sauberes Slow Log nicht immer, dass Benutzer sich Latenz nur einbilden.

Vergleichen Sie drei Ansichten:

redis-cli --latency -h <host> -p <port>
redis-cli --latency-history -h <host> -p <port>
redis-cli SLOWLOG GET 10

Wenn die Latenz hoch ist, aber SLOWLOG leer ist, überprüfen Sie Netzwerk, Client-Pools, Server-CPU-Sättigung, Fork-Aktivität, Persistenz oder große Antworten. Wenn SLOWLOG wiederholt teure Befehle anzeigt, beginnen Sie mit dem Befehl und dem Datenstrukturdesign.

Fügen Sie in Anwendungen Timings um Redis-Aufrufe an der Client-Grenze hinzu. Protokollieren Sie die Befehlsklasse, das Schlüsselmuster, die verstrichene Zeit und ob der Client auf eine Pool-Verbindung gewartet hat. Protokollieren Sie keine Geheimnisse oder vollständigen Nutzlasten. Eine kleine Menge strukturierter Zeitmessung beantwortet normalerweise, ob die Verzögerung innerhalb von Redis oder bevor der Befehl es überhaupt erreicht, auftritt.

Verwenden Sie die Befehls-Komplexität als Geruchstest

Redis-Befehle sind schnell, wenn sie eine kleine, begrenzte Datenmenge berühren. Sie werden riskant, wenn sie einen großen Keyspace scannen, eine riesige Sammlung zurückgeben oder Arbeit proportional zu einem großen Wert leisten.

Bevor Sie die Hardware beschuldigen, überprüfen Sie die Komplexität des Befehls in der Redis-Befehlsreferenz für Ihre Version. Sie müssen nicht jedes Komplexitätslabel auswendig lernen, aber die Form ist wichtig:

GET user:123 ist durch die Größe eines Werts begrenzt.
HGET profile:123 email ist durch eine Hash-Nachschlageoperation begrenzt.
SMEMBERS followers:celebrity gibt das gesamte Set zurück.
KEYS * scannt den gesamten Keyspace.
LRANGE queue 0 -1 gibt die gesamte Liste zurück.
ZREMRANGEBYSCORE kann eine große Anzahl von Mitgliedern eines sortierten Sets entfernen.

Das riskante Muster ist normalerweise „gib mir alles". Es kann monatelang funktionieren und dann fehlschlagen, wenn ein Set von Hunderten von Mitgliedern auf Millionen anwächst. Redis wurde nicht plötzlich langsam; die Daten haben den Punkt überschritten, an dem ein unbegrenzter Befehl sichtbar wurde.

Sicherere Alternativen für häufige langsame Muster

Ersetzen Sie Befehle für den gesamten Keyspace und die gesamte Sammlung durch inkrementelle Muster.

Für die Schlüsselsuche verwenden Sie SCAN:

redis-cli --scan --pattern 'user:*'

Für Sets verwenden Sie SSCAN:

SSCAN active_users 0 COUNT 500

Für Hashes verwenden Sie HSCAN:

HSCAN user:123:settings 0 COUNT 200

Für sortierte Sets bevorzugen Sie Bereiche mit expliziten Grenzen und Limits:

ZRANGE leaderboard 0 99 WITHSCORES
ZRANGEBYSCORE events 1716600000 1716686400 LIMIT 0 500

Für Listen blättern Sie mit begrenzten Bereichen:

LRANGE recent_jobs 0 99

SCAN ist inkrementell, aber keine magische kostenlose Operation. Es kann Duplikate zurückgeben und liefert keinen perfekt konsistenten Snapshot, während sich Schlüssel ändern. Es eignet sich gut für Wartung, Migration und Hintergrundsuche. Es ist normalerweise nicht das richtige Grundelement für einen benutzerseitigen Anforderungspfad, der eine präzise Echtzeitliste benötigt.

Große Antworten können die wahren Kosten sein

Ein Befehl kann schnell ausgeführt werden und dennoch Ihrer Anwendung schaden, wenn er zu viele Daten zurückgibt. SMEMBERS auf einem riesigen Set, HGETALL auf einem großen Hash oder MGET über Tausende von großen Werten können Zeit für die Serialisierung der Antwort und das Senden über das Netzwerk aufwenden. Diese Kosten werden möglicherweise nicht allein als Befehlsausführungszeit deutlich sichtbar.

Beobachten Sie die Netzwerkausgabe und den Client-Speicher während der langsamen Operation. Wenn eine einzelne Anforderung Dutzende oder Hunderte von Megabyte zurückgibt, gestalten Sie das Zugriffsmuster neu. Speichern Sie Zusammenfassungsdaten separat. Blättern Sie durch das Ergebnis. Verwenden Sie einen sortierten Set-Index und rufen Sie nur den sichtbaren Ausschnitt ab. Vermeiden Sie es, große Dokumente in Redis zu speichern, wenn die Anwendung normalerweise nur ein Feld benötigt.

Ein praktisches Beispiel: Wenn ein Dashboard die letzten 50 Jobs anzeigt, speichern Sie nicht jede Job-ID in einer Liste und rufen Sie LRANGE jobs 0 -1 auf, bevor Sie in der App slicen. Speichern Sie die Liste in der Reihenfolge „Neueste zuerst" und fordern Sie nur das an, was die Seite benötigt:

LRANGE jobs:recent 0 49

Diese kleine Änderung kann eine überraschende Menge an Latenz und Speicherdruck beseitigen.

MONITOR ist ein Skalpell, kein Dashboard

MONITOR ist nützlich, wenn Sie genau sehen müssen, welche Befehle ein Client sendet, insbesondere wenn Sie vermuten, dass die Anwendung etwas anderes tut, als die Code-Überprüfung vermuten lässt. Aber auf einem stark ausgelasteten Redis-Server erzeugt MONITOR Overhead und eine Flut von Ausgaben.

Verwenden Sie es für ein kurzes, kontrolliertes Fenster:

redis-cli MONITOR | head -n 200

Stoppen Sie es dann. Ziehen Sie in der Produktion nach Möglichkeit Stichproben aus Anwendungsprotokollen, Redis-Befehlsstatistiken oder einem kurzen Wartungsfenster vor.

INFO commandstats ist oft sicherer für eine breite Ansicht:

redis-cli INFO commandstats

Es zeigt befehlsbezogene Aufrufzahlen und kumulative Mikrosekunden. Es sagt Ihnen nicht, welcher Schlüssel langsam war, aber es kann aufdecken, dass eine Anwendung weit mehr HGETALL-, KEYS- oder EVAL-Aufrufe ausgibt als erwartet.

Lua-Skripte benötigen Grenzen

Lua-Skripte sind leistungsstark, weil sie atomar innerhalb von Redis ausgeführt werden. Dieses gleiche atomare Verhalten bedeutet, dass ein langes Skript andere Befehle blockiert, während es läuft. Langsame Skripte entstehen oft aus Schleifen über große Sammlungen, unbegrenzter Schlüsselsuche oder Logik, die von einem winzigen Helfer zu einer Mini-Anwendung herangewachsen ist.

Überprüfen Sie Skripte mit denselben Fragen:

Wie viele Schlüssel kann dieses Skript berühren?
Wie viele Elemente kann diese Schleife durchlaufen?
Was passiert, wenn der Eingabeschlüssel eine Million Mitglieder hat?
Kann die Arbeit in kleinere Stücke aufgeteilt werden?
Gibt das Skript eine große Nutzlast zurück?

Wenn ein Skript in SLOWLOG erscheint, widerstehen Sie der Versuchung, nur slowlog-log-slower-than zu erhöhen. Das Log sagt Ihnen, dass ein atomarer Block lange genug dauert, um andere Clients zu beeinträchtigen.

Persistenz, Forks und „langsame Befehle", die Symptome sind

Manchmal sind Befehle langsam, weil Redis mit Hintergrundarbeit beschäftigt ist. RDB-Snapshots und AOF-Rewrite-Operationen können CPU, Speicherdruck und Festplatten-I/O erhöhen. Unter Linux kann das Forken eines großen Redis-Prozesses auch Latenzspitzen erzeugen, insbesondere wenn Memory Overcommit, Huge Pages oder langsamer Speicher beteiligt sind.

Überprüfen Sie:

redis-cli INFO persistence
redis-cli INFO stats
redis-cli INFO memory
redis-cli LATENCY LATEST

Wenn Latenzspitzen mit Hintergrundspeicherungen oder AOF-Rewrites zusammenfallen, passen Sie die Persistenz sorgfältig an. Möglicherweise benötigen Sie schnelleren Speicher, angepasste Speicherrichtlinien, AOF-Rewrite-Schwellenwerte oder Speichereinstellungen. Deaktivieren Sie die Persistenz nicht nur, um einen Benchmark besser aussehen zu lassen, es sei denn, Redis ist ein reiner Wegwerf-Cache und das Unternehmen akzeptiert den Datenverlust.

Client-Verhalten kann Redis überlasten, ohne einen einzigen schlechten Befehl

Ein Redis-Server kann genauso durch Millionen winziger ineffizienter Aufrufe geschädigt werden wie durch einen offensichtlich langsamen Befehl. Eine Seite, die 200 sequentielle GET-Aufrufe tätigt, fühlt sich langsam an, selbst wenn jeder einzelne GET schnell ist.

Verwenden Sie Pipelining, wenn die Anwendung viele unabhängige Befehle benötigt und es tolerieren kann, Antworten zusammen zu erhalten:

GET user:1
GET user:2
GET user:3

gesendet als Pipeline vermeidet einen Roundtrip pro Befehl. Pipelining ist kein Ersatz für gutes Datenmodellieren und kann die Speichernutzung erhöhen, wenn Batches zu groß sind. Beginnen Sie mit bescheidenen Batch-Größen und messen Sie.

Überprüfen Sie auch Verbindungspools. Wenn Anwendungsprotokolle zeigen, dass Redis-Aufrufe 500 ms dauern, Redis aber keine langsamen Befehle sieht, wartet die App möglicherweise auf eine freie Verbindung. Erhöhen Sie den Pool nur, nachdem Sie überprüft haben, warum vorhandene Verbindungen beschäftigt sind. Ein größerer Pool kann das Symptom verbergen, während der Druck auf Redis erhöht wird.

Eine praktische Incident-Checkliste

Wenn Redis-Latenz Benutzer beeinträchtigt, sammeln Sie Fakten in dieser Reihenfolge:

date -u
redis-cli PING
redis-cli --latency -i 1
redis-cli SLOWLOG GET 20
redis-cli INFO commandstats
redis-cli INFO clients
redis-cli INFO memory
redis-cli INFO persistence
redis-cli LATENCY LATEST

Fragen Sie dann, was sich geändert hat: ein Deploy, ein neuer Endpunkt, ein Datenwachstumsereignis, ein Batch-Job, eine Migration, eine Dashboard-Abfrage, ein neues Cache-Schlüsselmuster oder ein Persistenz-Rewrite. Redis-Verlangsamungen sind oft an ein einzelnes Zugriffsmuster gebunden, das populär wurde, oder an einen Schlüssel, der viel größer wurde als erwartet.

Notieren Sie für jeden langsamen Befehl das Schlüsselmuster und den Eigentümer. „Langsames SMEMBERS" ist nicht genug. „Der Empfehlungsdienst ruft SMEMBERS product:123:viewers auf einem Set auf, das unbegrenzt wachsen kann" ist umsetzbar.

Zusammenfassung der Performance-Tuning-Checkliste

Aktivieren und Überwachen von SLOWLOG: Überprüfen Sie regelmäßig SLOWLOG GET, um wiederkehrende langsame Befehle zu identifizieren. Passen Sie slowlog-log-slower-than bei Bedarf an.
Verwenden Sie MONITOR mit Vorsicht: Für Echtzeit-Debugging bei vermuteten Verlangsamungen, aber deaktivieren Sie es sofort danach.
Vermeiden Sie KEYS auf großen Produktions-Keyspaces: Verwenden Sie SCAN für inkrementelle Iteration, wenn eine Schlüsselsuche wirklich erforderlich ist.
Optimieren Sie Lua-Skripte: Stellen Sie sicher, dass EVAL- und EVALSHA-Skripte effizient sind und nicht übermäßig lange laufen.
Verarbeiten Sie große Datenstrukturen iterativ: Verwenden Sie SSCAN, ZSCAN, LRANGE mit Limits oder SCAN, anstatt ganze Sammlungen abzurufen.
Analysieren Sie Befehlsargumente: Stellen Sie sicher, dass die an Befehle übergebenen Argumente kein unerwartetes Verhalten verursachen (z. B. sehr große Anzahlen, komplexe Muster).
Überwachen Sie Server-Ressourcen: Behalten Sie die CPU-, Speicher- und Netzwerkauslastung des Redis-Servers im Auge. Langsame Befehle können manchmal ein Symptom eines überlasteten Servers sein.
Client-seitige Optimierungen: Überprüfen Sie, ob Ihre Anwendung Befehle nicht zu schnell oder in ineffizienten Batches sendet. Erwägen Sie Pipelining für mehrere Befehle, wo angemessen.

Abschließende Überprüfung

Verwenden Sie SLOWLOG, um Befehle zu finden, die innerhalb von Redis langsam sind, Latenz-Tools, um Server-seitige Spitzen zu erkennen, und Anwendungs-Timing, um Client-Wartezeiten zu erkennen. Beheben Sie dann das Zugriffsmuster, nicht nur den Schwellenwert. Begrenzte Befehle, kleinere Antworten, sinnvolles Batching und klare Eigentümerschaft großer Schlüssel tun mehr für die Redis-Leistung als die Jagd nach einmaligen Optimierungsänderungen.