Häufig gestellte Fragen zur Azure Cache for Redis-Verwaltung

Anders als bei Azure Cache for Redis wird TLS von Redis-Servern nicht nativ unterstützt. Verwenden Sie TLS, wenn Sie eine Verbindung mit Azure Cache for Redis herstellen und Ihr Client TLS unterstützt (z. B. StackExchange.Redis).

Redis-Tools wie redis-cli funktionieren nicht mit dem TLS-Port, aber Sie können ein Hilfsprogramm wie stunnel verwenden, um eine sichere Verbindung zwischen den Tools und dem TLS-Port herzustellen. Anweisungen hierzu finden Sie im Blogbeitrag zur Ankündigung des ASP.NET-Sitzungsstatusanbieters für Redis-Vorschauversion.

Anweisungen zum Herunterladen der Redis-Tools finden Sie im Abschnitt Wie führe ich Redis-Befehle aus? .

• Best Practices für StackExchange.Redis
• Konfiguration und Konzepte
• Leistungstests

Best Practices für StackExchange.Redis

• Legen Sie AbortConnect auf „false“ fest, und lassen Sie dann den ConnectionMultiplexer automatisch eine neue Verbindung herstellen.
• Verwenden Sie eine einzelne, langlebige ConnectionMultiplexer-Instanz, anstatt eine neue Verbindung für jede Anforderung zu erstellen. Ein Beispiel für das Verwalten einer Verbindung finden Sie unter der RedisConnection-Klasse unter Verbinden mit dem Cache mit RedisConnection.
• Redis funktioniert am besten mit kleineren Werten, deshalb sollten Sie die Aufteilung großer Daten in mehrere Schlüssel erwägen. In dieser Diskussion zu Redis werden 100 KB als groß betrachtet. Weitere Informationen finden Sie unter Entwicklung bewährter Verfahren.
• Konfigurieren Sie Ihre ThreadPool-Einstellungen , um Timeouts zu verhindern.
• Verwenden Sie mindestens den Standardwert von 5 Sekunden für connectTimeout. Dieses Intervall gibt „StackExchange.Redis“ bei einer Netzwerkunterbrechung genügend Zeit zur erneuten Verbindungsherstellung.
• Berücksichtigen Sie die Leistungskosten für verschiedene Vorgänge, die Sie ausführen. Beispielsweise ist der KEYS -Befehl ein O(n)-Vorgang und sollte vermieden werden. Die redis.io-Website umfasst Details zur Zeitkomplexität für jeden unterstützten Vorgang. Wählen Sie Befehle aus, um die Komplexität des jeweiligen Vorgangs anzuzeigen.

Konfiguration und Konzepte

• Verwenden Sie den Standard- oder Premium-Tarif für Produktionssysteme. Der Basic-Tarif ist ein System mit einem einzelnen Knoten, ohne Datenreplikation und ohne SLA. Verwenden Sie mindestens einen C1-Cache. C0-Caches werden in der Regel für einfache Entwicklungs-/Testszenarien verwendet.
• Beachten Sie, dass Redis ein In-Memory -Datenspeicher ist. Weitere Informationen finden Sie unter Fehlerbehebung bei Datenverlust in Azure Cache for Redis, damit Sie wissen, in welchen Fällen Datenverluste auftreten können.
• Entwickeln Sie Ihr System so, dass es mit Verbindungsabbrüchen aufgrund von Patches und Failover umgehen kann.

Leistungstests

• Starten Sie mit der Verwendung von redis-benchmark.exe , um den möglichen Durchsatz einschätzen zu können, bevor Sie Ihre eigenen Leistungstests schreiben. Weil redis-benchmark TLS nicht unterstützt, müssen Sie den nicht für TLS bestimmten Port über das Azure-Portal aktivieren, bevor Sie den Test ausführen. Beispiele finden Sie unter Wie kann ich die Leistung meines Caches messen und testen?
• Die für den Test verwendete Client-VM sollte sich in derselben Region befinden wie Ihre Azure Cache for Redis-Instanz.
• Es wird empfohlen, die Dv2-VM-Serie für Ihren Client zu verwenden, da sie über bessere Hardware verfügt und die besten Ergebnisse liefern dürfte.
• Stellen Sie sicher, dass die von Ihnen ausgewählte Client-VM mindestens über die gleiche Computing- und Bandbreitenkapazität wie der getestete Cache verfügt.
• Aktivieren Sie VRSS auf dem Clientcomputer, wenn Sie unter Windows arbeiten. Ausführliche Informationen finden Sie hier.
• Redis-Instanzen im Premium-Tarif verfügen über eine geringere Netzwerklatenz und einen höheren Durchsatz, weil sowohl die CPU als auch das Netzwerk auf besserer Hardware ausgeführt werden.

• Vermeiden Sie die Verwendung bestimmter Redis-Befehle mit langer Ausführungszeit, sofern Sie nicht vollständig mit deren Auswirkungen vertraut sind. Führen Sie den Befehl KEYS beispielsweise nicht in der Produktion aus. Die Rückgabe könnte in Abhängigkeit von der Anzahl von Schlüsseln sehr viel Zeit in Anspruch nehmen. Redis ist ein Server mit Single-Threading, d. h. Befehle werden nacheinander verarbeitet. Wenn Sie nach KEYS weitere Befehle ausführen, werden diese erst verarbeitet, nachdem Redis den KEYS-Befehl verarbeitet hat. Die redis.io-Website umfasst Details zur Zeitkomplexität für jeden unterstützten Vorgang. Wählen Sie Befehle aus, um die Komplexität des jeweiligen Vorgangs anzuzeigen.
• Schlüsselgrößen – sollte ich kleine Schlüssel/Werte oder große Schlüssel/Werte verwenden? Dies hängt vom Szenario ab. Wenn Ihre Szenarios größere Schlüssel erfordern, können Sie den ConnectionTimeout anpassen, dann die Werte erneut ausprobieren und Ihre Logik für erneute Verbindungsversuche anpassen. In Bezug auf den Redis-Server führen kleinere Werte zu einer besseren Leistung.
• Diese Überlegungen bedeuten jedoch nicht, dass Sie in Redis keine größeren Werte speichern können – Sie müssen sich lediglich der folgenden Punkte bewusst sein. Latenzen sind höher. Wenn Sie einen größeren und einen kleineren Datensatz haben, können Sie mehrere ConnectionMultiplexer-Instanzen verwenden. Konfigurieren Sie beide mit unterschiedlichen Werten für Timeout und Wiederholung, wie dies im vorherigen Abschnitt Was bewirken die Konfigurationsoptionen für „StackExchange.Redis“? beschrieben ist.

• Aktivieren Sie die Cachediagnose, damit Sie die Integrität Ihres Caches überwachen können. Sie können die Metriken im Azure-Portal anzeigen und anschließend mit einem Tool Ihrer Wahl herunterladen und prüfen .
• Mit "redis-benchmark.exe" können Sie Auslastungstests für Ihren Redis-Server durchführen.
• Stellen Sie sicher, dass sich Client und Azure Cache for Redis für die Auslastungstests in derselben Region befinden.
• Verwenden Sie "redis-cli.exe", und überwachen Sie den Cache unter Verwendung des INFO-Befehls.
• Wenn Ihre Datenlast zu einer hohen Arbeitsspeicherfragmentierung führt, sollten Sie eine Hochskalierung auf einen größeren Cache durchführen.
• Anweisungen zum Herunterladen der Redis-Tools finden Sie im Abschnitt Wie führe ich Redis-Befehle aus? .

Hier sind einige Beispiele für die Verwendung von „redis-benchmark.exe“ angegeben. Führen Sie diese Befehle über eine VM in derselben Region wie Ihr Cache aus, um genaue Ergebnisse zu erhalten (cache-development-faq.yml).

• Test von SET-Anforderungen in der Pipeline mithilfe einer 1-K-Nutzlast

  redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t SET -n 1000000 -d 1024 -P 50

• Test von GET-Anforderungen in der Pipeline mithilfe einer 1-K-Nutzlast

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

Der CLR-Threadpool enthält zwei Typen von Threads: Workerthreads und E/A-Abschlussportthreads (IOCP, I/O Completion Port).

• Workerthreads werden für Vorgänge wie das Verarbeiten der Methoden Task.Run(…) oder ThreadPool.QueueUserWorkItem(…) verwendet. Diese Threads werden auch von verschiedenen Komponenten in der CLR verwendet, wenn Arbeitsvorgänge in einem Hintergrundthread ausgeführt werden müssen.
• IOCP-Threads werden verwendet, wenn asynchrone E/A-Vorgänge ausgeführt werden, z. B. beim Lesen aus dem Netzwerk.

Der Threadpool stellt neue Workerthreads oder E/A-Abschlussthreads nach Bedarf (und ohne Drosselung) bereit, bis die Einstellung für das Minimum des jeweiligen Threadtyps erreicht ist. Standardmäßig entspricht die minimale Anzahl von Threads der Anzahl von Prozessoren in einem System.

Wenn die Anzahl der vorhandenen (ausgelasteten) Threads die „minimale“ Anzahl von Threads erreicht, drosselt der Threadpool die Rate, mit der er neue Threads hinzufügt, auf einen Thread pro 500 Millisekunden. Wenn bei Ihrem System eine Arbeitsspitze eingeht, die einen IOCP-Thread benötigt, werden diese Arbeitsvorgänge in der Regel schnell verarbeitet. Wenn für die Spitze jedoch mehr Threads erforderlich sind, als in der konfigurierten Einstellung für das Minimum vorgesehen sind, tritt eine gewisse Verzögerung bei der Verarbeitung einiger Arbeitsvorgänge auf. Der Threadpool wartet darauf, dass einer von zwei möglichen Fällen eintritt:

• Ein vorhandener Thread wird frei, um die Arbeitsvorgänge zu verarbeiten.
• Es wird 500 ms lang kein vorhandener Thread frei, und ein neuer Thread wird erstellt.

Wenn die Anzahl ausgelasteter Threads also größer als die minimale Anzahl von Threads ist, muss wahrscheinlich eine Verzögerung von 500 ms in Kauf genommen werden, bevor der Netzwerkdatenverkehr von der Anwendung verarbeitet wird. Zudem werden Threads nach einer längeren Leerlaufdauer als 15 Sekunden bereinigt, und der Zyklus aus Wachstum und Schrumpfung kann fortgesetzt werden.

Am Beispiel einer Fehlermeldung aus „StackExchange.Redis“ (Build 1.0.450 oder höher) ist zu sehen, dass nun Threadpool-Statistiken ausgegeben werden. Informationen zu IOCP und WORKER finden Sie weiter unten.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

Wie im Beispiel zu sehen ist, sind bei den IOCP-Threads sechs Threads ausgelastet, und das System ist für ein Minimum von vier Threads konfiguriert. In diesem Fall wird der Client wahrscheinlich zwei Verzögerungen von 500 ms verzeichnet haben, weil 6 größer als 4 ist.

Empfehlung

Vor dem Hintergrund dieser Informationen empfehlen wir dringend, als minimalen Wert für IOCP- und WORKER-Threads einen höheren Wert als den Standardwert zu konfigurieren. Wir können keine allgemeingültigen Richtlinien zur Größe dieses Werts geben, weil der richtige Wert für eine Anwendung für eine andere Anwendung wahrscheinlich zu hoch oder zu niedrig sein wird. Diese Einstellung kann sich auch auf die Leistung anderer Teile komplexer Anwendungen auswirken. Daher müssen Kunden diese Einstellung gemäß ihren jeweiligen Anforderungen optimieren. Ein guter Ausgangspunkt sind 200 oder 300 Threads. Testen Sie diese Einstellung, und passen Sie sie nach Bedarf an.

So konfigurieren Sie diese Einstellung:

• Wir empfehlen, diese Einstellung programmgesteuert zu ändern, indem Sie die ThreadPool.SetMinThreads (...) -Methode in global.asax.cs verwenden. Beispiel:

  private readonly int minThreads = 200;
  void Application_Start(object sender, EventArgs e)
  {
      // Code that runs on application startup
      AreaRegistration.RegisterAllAreas();
      RouteConfig.RegisterRoutes(RouteTable.Routes);
      BundleConfig.RegisterBundles(BundleTable.Bundles);
      ThreadPool.SetMinThreads(minThreads, minThreads);
  }
  

  Hinweis

  Der von dieser Methode festgelegte Wert ist eine globale Einstellung, die die gesamte AppDomain betrifft. Wenn Sie beispielsweise über einen Computer mit vier Kernen verfügen und minWorkerThreads und minIOThreads zur Laufzeit auf 50 pro CPU festlegen möchten, verwenden Sie ThreadPool.SetMinThreads (200, 200).

• Außerdem können Sie die Einstellung für die Mindestanzahl von Threads mithilfe der Konfigurationseinstellungen minIoThreads bzw. minWorkerThreads unter dem Konfigurationselement <processModel> in Machine.config festlegen. Machine.config befindet sich in der Regel unter %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\. Es wird nicht empfohlen, die Mindestanzahl von Threads auf diese Weise festzulegen, weil es sich um eine systemweite Einstellung handelt.

  Hinweis

  Der in diesem Konfigurationselement angegebene Wert ist eine Einstellung pro Kern. Wenn Ihr Computer z.B. über vier Kerne verfügt und Sie eine minIoThreads-Einstellung von 200 zur Laufzeit festlegen möchten, müssen Sie <processModel minIoThreads="50"/> verwenden.

Das Aktivieren der Garbage Collection auf dem Server kann den Client optimieren und bei Verwenden von „StackExchange.Redis“ mehr Leistung und Durchsatz ermöglichen. Weitere Informationen zur Garbage Collection auf dem Server und ihrer Aktivierung finden Sie in den folgenden Artikeln:

• So aktivieren Sie die Garbage Collection auf dem Server
• Grundlagen der Garbage Collection
• Garbage Collection und Leistung

Jeder Tarif hat verschiedene Limits für Clientverbindungen, Speicher und Bandbreite. Für jede Cachegröße ist eine maximale Anzahl von Verbindungen zulässig, aber für jede Verbindung zu Redis fällt Mehraufwand an. Ein Beispiel für einen solchen Aufwand ist die CPU- und Arbeitsspeicherauslastung aufgrund der TLS-/SSL-Verschlüsselung. Das maximale Verbindungslimit für eine angegebene Cachegröße geht von einem geringfügig ausgelasteten Cache aus. Wenn die Last des Verbindungsaufwands und die Last von Clientvorgängen zusammen die Systemkapazität überschreiten, können im Cache Kapazitätsprobleme entstehen. Dies gilt auch, wenn Sie das Verbindungslimit für die aktuelle Cachegröße nicht überschritten haben.

Weitere Informationen zu den verschiedenen Verbindungsgrenzwerten für die einzelnen Ebenen finden Sie unter Azure Cache for Redis – Preise. Weitere Informationen zu Verbindungen und anderen Standardkonfigurationen finden Sie unter Standardmäßige Redis-Serverkonfiguration.

Nächste Schritte

Erfahren Sie mehr über weitere häufig gestellte Fragen zu Azure Cache for Redis.