Häufig gestellte Fragen zur Cache-Verwaltung

Dieser Artikel bietet Antworten auf häufig gestellte Fragen zur Verwaltung von Azure Cache for Redis.

Von Bedeutung

Azure Cache for Redis hat den Auslaufzeitplan für alle SKUs angekündigt. Es wird empfohlen, Ihren vorhandenen Azure-Cache für Redis-Instanzen in Azure Managed Redis zu verschieben, sobald Möglich.

Weitere Informationen zur Einstellung finden Sie unter:

• Einstellung von Azure Cache for Redis: Was Sie wissen müssen und wie Sie sich vorbereiten
• Häufig gestellte Fragen zur Einstellung von Azure Cache for Redis

Wie kann ich die Leistung meines Caches messen und testen?

• Verwenden Sie redis-benchmark.exe, um einen Lasttest für Ihren Redis-Server durchzuführen. Verwenden Sie redis-benchmark.exe, um ein Gefühl für den möglichen Durchsatz zu bekommen, bevor Sie Ihre eigenen Leistungstests schreiben.
• Verwenden Sie redis-cli, um den Cache mit dem Befehl INFO zu überwachen. Anweisungen zum Herunterladen der Redis-Tools finden Sie unter Wie kann ich Redis-Befehle ausführen?
• Wenn Sie Transport Layer Security/Secure Socket Layer (TLS/SSL) auf Ihrer Cache-Instanz verwenden, fügen Sie den Parameter --tls zu Ihren Redis-Tools-Befehlen hinzu oder verwenden Sie einen Proxy wie stunnel zum Aktivieren von TLS/SSL.
• Redis-benchmark Verwendet standardmäßig Port 6379. Verwenden Sie den Parameter -p, um diese Einstellung zu überschreiben, wenn Ihr Cache den SSL/TLS-Port 6380 oder den Enterprise-Port 10000 verwendet.
• Bei Bedarf können Sie den Nicht-TLS-Port über das Azure-Portal aktivieren, bevor Sie den Auslastungstest ausführen.
• Stellen Sie sicher, dass sich der virtuelle Clientcomputer (VM), den Sie zum Testen verwenden, in derselben Region wie Ihre Azure Cache for Redis-Instanz befindet.
• Stellen Sie sicher, dass Ihre Client-VM über mindestens so viel Rechen- und Bandbreitenkapazität verfügt wie der Cache, den Sie testen. Die besten Ergebnisse erzielen Sie, wenn Sie VMs der D-Serie und der E-Serie für Ihre Clients verwenden.
• Wenn Sie Windows verwenden, aktivieren Sie Virtual Receive-Side Scaling (VRSS) auf dem Clientcomputer. Weitere Informationen finden Sie unter Neues bei der virtuellen empfangsseitigen Skalierung unter Windows Server 2012 R2.
• 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.
• Wenn Ihre Datenlast zu einer hohen Arbeitsspeicherfragmentierung führt, führen Sie eine Hochskalierung auf einen größeren Cache durch.

In den folgenden Beispielen wird gezeigt, wie Sie redis-benchmark.exe verwenden. Führen Sie diese Befehle von einer VM in der gleichen Region wie Ihr Cache aus, um genaue Ergebnisse zu erhalten.

Testen Sie zunächst die wartenden SET-Anfragen mit einer 1k-Nutzlast:

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

Führen Sie nach dem Ausführen des SET-Tests weitergeleitete GET-Anforderungen mit einer 1k-Nutzlast aus:

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

Wie aktiviere ich die Garbage Collection auf dem Server, um bei Verwenden von „StackExchange.Redis“ mehr Durchsatz auf dem Client zu erzielen?

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:

• Das <gcServer>-Element
• Grundlagen der Garbage Collection
• Garbage Collection und Leistung

Sollte ich den nicht für TLS/SSL bestimmten Port für die Verbindung mit Redis aktivieren?

Der Redis-Server unterstützt TLS (Transport Layer Security) nicht nativ, aber Azure Cache for Redis unterstützt TLS. Wenn Sie eine Verbindung mit Azure Cache for Redis mit einem Client wie StackExchange.Redis herstellen, der TLS unterstützt, verwenden Sie TLS.

Hinweis

Der Nicht-TLS-Port ist für neue Azure Redis-Instanzen standardmäßig deaktiviert. Wenn Ihr Client TLS nicht unterstützt, aktivieren Sie den Nicht-TLS-Port, indem Sie die Anweisungen unter Zugriffsports befolgen.

Wenn der Cache TLS verwendet, müssen Sie TLS aktivieren, indem Sie die Option --tls für Redis-Tools wie redis-cli verwenden. Sie können auch ein Hilfsprogramm verwenden, z. B. stunnel, um die Tools sicher mit dem TLS-Port zu verbinden, indem Sie die Anweisungen im Blogbeitrag Ankündigung ASP.NET Sitzungszustandsanbieters für Redis Preview Release befolgen.

Anweisungen zum Herunterladen der Redis-Tools finden Sie unter Wie kann ich Redis-Befehle ausführen?

Was ist bei der Verwendung gängiger Redis-Befehle zu beachten?

• 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 Singlethread-Server, der Befehle nacheinander verarbeitet. Wenn Sie den Befehl KEYS ausgeben, verarbeitet Redis nachfolgende Befehle erst, wenn die Verarbeitung des Befehls KEYS abgeschlossen ist.

  Die Website redis.io verfügt über Details zur Zeitkomplexität für jeden Vorgang, den sie unterstützt. Wählen Sie Befehle aus, um die Komplexität des jeweiligen Vorgangs anzuzeigen.

• Welche Schlüsselgröße verwendet werden soll, hängt vom Szenario ab. Wenn Ihr Szenario 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 Schlüsselwerte zu einer besseren Leistung.

• Diese Überlegungen bedeuten nicht, dass Sie keine größeren Werte in Redis speichern können, aber die Latenzen sind höher. Wenn Sie über einen Datensatz verfügen, der größer als ein anderer ist, können Sie mehrere ConnectionMultiplexer-Instanzen verwenden, die jeweils mit einem anderen Satz von Timeout- und Wiederholungswerten konfiguriert sind. Weitere Informationen finden Sie unter Was bewirken die StackExchange.Redis-Konfigurationsoptionen?

Welche Leistungsüberlegungen gibt es bei Verbindungen?

Jeder Azure Cache for Redis-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 Verbindungsmehraufwands plus die Last von Clientvorgängen die Kapazität für das System überschreiten, können im Cache Kapazitätsprobleme entstehen, selbst wenn Sie das Verbindungslimit für die aktuelle Cachegröße nicht überschreiten.

Weitere Informationen zu den 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.

Welche Best Practices gelten für die Produktion?

• 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 außerdem mindestens einen C1-Cache für die Produktion. C0-Caches werden in der Regel für einfache Entwicklungs-/Testszenarien verwendet.
• Beachten Sie, dass es sich bei Redis um einen In-Memory-Datenspeicher handelt, und dass es in einigen Szenarien zu Datenverlusten kommen kann. Weitere Informationen finden Sie unter Problembehandlung bei Datenverlusten in Azure Cache for Redis.
• Entwickeln Sie Ihr System so, dass es Verbindungsausfälle bewältigen kann, die durch Patching und Failover verursacht werden.
• Verwenden Sie Redis-Instanzen im Premium-Tarif für eine geringere Netzwerklatenz und einen höheren Durchsatz, weil sowohl die CPU als auch das Netzwerk auf besserer Hardware ausgeführt werden.

Best Practices für StackExchange.Redis

• Legen Sie AbortConnect auf false fest, und lassen Sie ConnectionMultiplexer die Verbindung automatisch wiederherstellen.
• Verwenden Sie eine einzelne, langlebige ConnectionMultiplexer-Instanz, anstatt eine neue Verbindung für jede Anforderung zu erstellen.
• Redis funktioniert am besten mit kleineren Werten, deshalb sollten Sie die Aufteilung großer Daten in mehrere Schlüssel erwägen. In Was ist der ideale Wertegrößenbereich für Redis? wird z. B. 100 KB als groß angesehen. Weitere Informationen finden Sie unter Berücksichtigen von mehr Schlüsseln und kleineren Werten.
• Konfigurieren Sie Ihre ThreadPool-Einstellungen , um Timeouts zu verhindern.
• Verwenden Sie mindestens den Standardwert für connectTimeout von 5 Sekunden. 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 Website redis.io enthält Details zur Zeitkomplexität der einzelnen Vorgänge, die sie unterstützt. Wählen Sie Befehle aus, um die Komplexität des jeweiligen Vorgangs anzuzeigen.

Wichtige Details zum Threadpool-Wachstum

Der Common Language Runtime (CLR)-ThreadPool enthält zwei Typen von Threads: Worker und E/A-Abschlussport (IOCP, I/O Completion Port).

• WORKER-Threads werden für Dinge wie die Verarbeitung von Task.Run(…)- oder ThreadPool.QueueUserWorkItem(…)-Methoden verwendet. Verschiedene Komponenten in der CLR verwenden diese Threads auch, wenn Arbeiten in einem Hintergrundthread ausgeführt werden müssen.
• IOCP-Threads werden für asynchrone I/O verwendet, 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 minimum Threadnummer erreicht, drosselt der ThreadPool die Rate, mit der er neue Threads injiziert, auf einen Thread pro 500 Millisekunden.

Wenn bei Ihrem System ein Burst auftritt, die einen IOCP-Thread benötigt, werden diese Arbeitsvorgänge in der Regel schnell verarbeitet. Wenn für den Burst 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, weshalb dann ein neuer Thread erstellt wird.

Wenn die Anzahl der Busy-Threads größer als die Anzahl der Min-Threads ist, tritt grundsätzlich eine Verzögerung von 500 ms auf, bevor die Anwendung den Netzwerkdatenverkehr verarbeitet. Zudem werden Threads nach einer längeren Leerlaufdauer als 15 Sekunden bereinigt, und der Zyklus aus Wachstum und Schrumpfung kann fortgesetzt werden.

Fehlermeldungen von StackExchange.Redis Build 1.0.450 oder höher drucken ThreadPool-Statistiken, wie im folgenden Beispiel gezeigt.

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)

Das Beispiel zeigt, dass für den IOCP-Thread sechs ausgelastete Threads vorhanden sind und das System so konfiguriert ist, dass mindestens vier Threads zulässig sind. In diesem Fall werden auf dem Client wahrscheinlich zwei Verzögerungen von 500 ms angezeigt, da 6 > 4.

Hinweis

Für „StackExchange.Redis“ kann ein Timeout eintreten, wenn IOCP- oder WORKER-Threads gedrosselt werden.

Es empfiehlt sich, den minimalen Konfigurationswert für IOCP- und WORKER-Threads auf einen Wert festzulegen, der größer als der Standardwert ist. Es gibt keine allgemeingültige Anleitung für diesen Wert, da der richtige Wert für eine Anwendung wahrscheinlich zu hoch oder zu niedrig für eine andere Anwendung ist. Diese Einstellung kann sich auch auf die Leistung anderer Teile komplizierter Anwendungen auswirken. Sie müssen diese Einstellung an Ihre spezifischen Bedürfnisse anpassen. Ein guter Ausgangspunkt ist 200 oder 300. Testen und optimieren Sie dann nach Bedarf.

Konfigurieren der Einstellung für die Mindestanzahl von Threads

Sie können diese Einstellung programmgesteuert mit der Methode ThreadPool.SetMinThreads (...) ändern.

In NET Framework legen Sie z. B. diesen Wert in Global.asax.cs in der Methode Application_Start fest:

    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);
    }

Wenn Sie .NET Core verwenden, legen Sie den Wert in Program.cs direkt vor dem Aufruf auf WebApplication.CreateBuilder() fest:

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Hinweis

Der von dieser Methode angegebene Wert ist eine globale Einstellung, die sich auf die gesamte AppDomain auswirkt. Wenn Sie z. B. über eine VM mit vier Kernen verfügen und während der Laufzeit minWorkerThreads und minIoThreads auf 50 pro CPU festlegen möchten, verwenden Sie ThreadPool.SetMinThreads(200, 200).

Sie können die Einstellung für die minimale Anzahl von Threads auch mithilfe der minIoThreadsminWorkerThreads oder im Konfigurationselement <processModel> in Machine.config angeben. 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. Wenn Sie auf diese Weise die Mindestanzahl von Threads festlegen, müssen Sie den Anwendungspool neu starten.

Hinweis

Der von dieser Methode angegebene Wert ist eine Einstellung pro Kern. Wenn Sie z. B. über einen Computer mit vier Kernen verfügen und für minIoThreads zur Laufzeit eine Einstellung von 200 festlegen möchten, verwenden Sie <processModel minIoThreads="50">.

Verwandte Inhalte

• Weitere Informationen finden Sie in anderen häufig gestellten Fragen zu Azure Cache for Redis.

Dieser Artikel bietet Antworten auf häufig gestellte Fragen zur Verwaltung von Azure Cache for Redis.

Von Bedeutung

Azure Cache for Redis hat den Auslaufzeitplan für alle SKUs angekündigt. Es wird empfohlen, Ihren vorhandenen Azure-Cache für Redis-Instanzen in Azure Managed Redis zu verschieben, sobald Möglich.

Weitere Informationen zur Einstellung finden Sie unter:

• Einstellung von Azure Cache for Redis: Was Sie wissen müssen und wie Sie sich vorbereiten
• Häufig gestellte Fragen zur Einstellung von Azure Cache for Redis

• Verwenden Sie redis-benchmark.exe, um einen Lasttest für Ihren Redis-Server durchzuführen. Verwenden Sie redis-benchmark.exe, um ein Gefühl für den möglichen Durchsatz zu bekommen, bevor Sie Ihre eigenen Leistungstests schreiben.
• Verwenden Sie redis-cli, um den Cache mit dem Befehl INFO zu überwachen. Anweisungen zum Herunterladen der Redis-Tools finden Sie unter Wie kann ich Redis-Befehle ausführen?
• Wenn Sie Transport Layer Security/Secure Socket Layer (TLS/SSL) auf Ihrer Cache-Instanz verwenden, fügen Sie den Parameter --tls zu Ihren Redis-Tools-Befehlen hinzu oder verwenden Sie einen Proxy wie stunnel zum Aktivieren von TLS/SSL.
• Redis-benchmark Verwendet standardmäßig Port 6379. Verwenden Sie den Parameter -p, um diese Einstellung zu überschreiben, wenn Ihr Cache den SSL/TLS-Port 6380 oder den Enterprise-Port 10000 verwendet.
• Bei Bedarf können Sie den Nicht-TLS-Port über das Azure-Portal aktivieren, bevor Sie den Auslastungstest ausführen.
• Stellen Sie sicher, dass sich der virtuelle Clientcomputer (VM), den Sie zum Testen verwenden, in derselben Region wie Ihre Azure Cache for Redis-Instanz befindet.
• Stellen Sie sicher, dass Ihre Client-VM über mindestens so viel Rechen- und Bandbreitenkapazität verfügt wie der Cache, den Sie testen. Die besten Ergebnisse erzielen Sie, wenn Sie VMs der D-Serie und der E-Serie für Ihre Clients verwenden.
• Wenn Sie Windows verwenden, aktivieren Sie Virtual Receive-Side Scaling (VRSS) auf dem Clientcomputer. Weitere Informationen finden Sie unter Neues bei der virtuellen empfangsseitigen Skalierung unter Windows Server 2012 R2.
• 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.
• Wenn Ihre Datenlast zu einer hohen Arbeitsspeicherfragmentierung führt, führen Sie eine Hochskalierung auf einen größeren Cache durch.

In den folgenden Beispielen wird gezeigt, wie Sie redis-benchmark.exe verwenden. Führen Sie diese Befehle von einer VM in der gleichen Region wie Ihr Cache aus, um genaue Ergebnisse zu erhalten.

Testen Sie zunächst die wartenden SET-Anfragen mit einer 1k-Nutzlast:

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

Führen Sie nach dem Ausführen des SET-Tests weitergeleitete GET-Anforderungen mit einer 1k-Nutzlast aus:

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

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:

• Das <gcServer>-Element
• Grundlagen der Garbage Collection
• Garbage Collection und Leistung

Der Redis-Server unterstützt TLS (Transport Layer Security) nicht nativ, aber Azure Cache for Redis unterstützt TLS. Wenn Sie eine Verbindung mit Azure Cache for Redis mit einem Client wie StackExchange.Redis herstellen, der TLS unterstützt, verwenden Sie TLS.

Hinweis

Der Nicht-TLS-Port ist für neue Azure Redis-Instanzen standardmäßig deaktiviert. Wenn Ihr Client TLS nicht unterstützt, aktivieren Sie den Nicht-TLS-Port, indem Sie die Anweisungen unter Zugriffsports befolgen.

Wenn der Cache TLS verwendet, müssen Sie TLS aktivieren, indem Sie die Option --tls für Redis-Tools wie redis-cli verwenden. Sie können auch ein Hilfsprogramm verwenden, z. B. stunnel, um die Tools sicher mit dem TLS-Port zu verbinden, indem Sie die Anweisungen im Blogbeitrag Ankündigung ASP.NET Sitzungszustandsanbieters für Redis Preview Release befolgen.

Anweisungen zum Herunterladen der Redis-Tools finden Sie unter Wie kann ich Redis-Befehle ausführen?

• 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 Singlethread-Server, der Befehle nacheinander verarbeitet. Wenn Sie den Befehl KEYS ausgeben, verarbeitet Redis nachfolgende Befehle erst, wenn die Verarbeitung des Befehls KEYS abgeschlossen ist.

  Die Website redis.io verfügt über Details zur Zeitkomplexität für jeden Vorgang, den sie unterstützt. Wählen Sie Befehle aus, um die Komplexität des jeweiligen Vorgangs anzuzeigen.

• Welche Schlüsselgröße verwendet werden soll, hängt vom Szenario ab. Wenn Ihr Szenario 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 Schlüsselwerte zu einer besseren Leistung.

• Diese Überlegungen bedeuten nicht, dass Sie keine größeren Werte in Redis speichern können, aber die Latenzen sind höher. Wenn Sie über einen Datensatz verfügen, der größer als ein anderer ist, können Sie mehrere ConnectionMultiplexer-Instanzen verwenden, die jeweils mit einem anderen Satz von Timeout- und Wiederholungswerten konfiguriert sind. Weitere Informationen finden Sie unter Was bewirken die StackExchange.Redis-Konfigurationsoptionen?

Jeder Azure Cache for Redis-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 Verbindungsmehraufwands plus die Last von Clientvorgängen die Kapazität für das System überschreiten, können im Cache Kapazitätsprobleme entstehen, selbst wenn Sie das Verbindungslimit für die aktuelle Cachegröße nicht überschreiten.

Weitere Informationen zu den 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.

• 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 außerdem mindestens einen C1-Cache für die Produktion. C0-Caches werden in der Regel für einfache Entwicklungs-/Testszenarien verwendet.
• Beachten Sie, dass es sich bei Redis um einen In-Memory-Datenspeicher handelt, und dass es in einigen Szenarien zu Datenverlusten kommen kann. Weitere Informationen finden Sie unter Problembehandlung bei Datenverlusten in Azure Cache for Redis.
• Entwickeln Sie Ihr System so, dass es Verbindungsausfälle bewältigen kann, die durch Patching und Failover verursacht werden.
• Verwenden Sie Redis-Instanzen im Premium-Tarif für eine geringere Netzwerklatenz und einen höheren Durchsatz, weil sowohl die CPU als auch das Netzwerk auf besserer Hardware ausgeführt werden.

Best Practices für StackExchange.Redis

• Legen Sie AbortConnect auf false fest, und lassen Sie ConnectionMultiplexer die Verbindung automatisch wiederherstellen.
• Verwenden Sie eine einzelne, langlebige ConnectionMultiplexer-Instanz, anstatt eine neue Verbindung für jede Anforderung zu erstellen.
• Redis funktioniert am besten mit kleineren Werten, deshalb sollten Sie die Aufteilung großer Daten in mehrere Schlüssel erwägen. In Was ist der ideale Wertegrößenbereich für Redis? wird z. B. 100 KB als groß angesehen. Weitere Informationen finden Sie unter Berücksichtigen von mehr Schlüsseln und kleineren Werten.
• Konfigurieren Sie Ihre ThreadPool-Einstellungen , um Timeouts zu verhindern.
• Verwenden Sie mindestens den Standardwert für connectTimeout von 5 Sekunden. 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 Website redis.io enthält Details zur Zeitkomplexität der einzelnen Vorgänge, die sie unterstützt. Wählen Sie Befehle aus, um die Komplexität des jeweiligen Vorgangs anzuzeigen.

Der Common Language Runtime (CLR)-ThreadPool enthält zwei Typen von Threads: Worker und E/A-Abschlussport (IOCP, I/O Completion Port).

• WORKER-Threads werden für Dinge wie die Verarbeitung von Task.Run(…)- oder ThreadPool.QueueUserWorkItem(…)-Methoden verwendet. Verschiedene Komponenten in der CLR verwenden diese Threads auch, wenn Arbeiten in einem Hintergrundthread ausgeführt werden müssen.
• IOCP-Threads werden für asynchrone I/O verwendet, 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 minimum Threadnummer erreicht, drosselt der ThreadPool die Rate, mit der er neue Threads injiziert, auf einen Thread pro 500 Millisekunden.

Wenn bei Ihrem System ein Burst auftritt, die einen IOCP-Thread benötigt, werden diese Arbeitsvorgänge in der Regel schnell verarbeitet. Wenn für den Burst 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, weshalb dann ein neuer Thread erstellt wird.

Wenn die Anzahl der Busy-Threads größer als die Anzahl der Min-Threads ist, tritt grundsätzlich eine Verzögerung von 500 ms auf, bevor die Anwendung den Netzwerkdatenverkehr verarbeitet. Zudem werden Threads nach einer längeren Leerlaufdauer als 15 Sekunden bereinigt, und der Zyklus aus Wachstum und Schrumpfung kann fortgesetzt werden.

Fehlermeldungen von StackExchange.Redis Build 1.0.450 oder höher drucken ThreadPool-Statistiken, wie im folgenden Beispiel gezeigt.

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)

Das Beispiel zeigt, dass für den IOCP-Thread sechs ausgelastete Threads vorhanden sind und das System so konfiguriert ist, dass mindestens vier Threads zulässig sind. In diesem Fall werden auf dem Client wahrscheinlich zwei Verzögerungen von 500 ms angezeigt, da 6 > 4.

Hinweis

Für „StackExchange.Redis“ kann ein Timeout eintreten, wenn IOCP- oder WORKER-Threads gedrosselt werden.

Es empfiehlt sich, den minimalen Konfigurationswert für IOCP- und WORKER-Threads auf einen Wert festzulegen, der größer als der Standardwert ist. Es gibt keine allgemeingültige Anleitung für diesen Wert, da der richtige Wert für eine Anwendung wahrscheinlich zu hoch oder zu niedrig für eine andere Anwendung ist. Diese Einstellung kann sich auch auf die Leistung anderer Teile komplizierter Anwendungen auswirken. Sie müssen diese Einstellung an Ihre spezifischen Bedürfnisse anpassen. Ein guter Ausgangspunkt ist 200 oder 300. Testen und optimieren Sie dann nach Bedarf.

Konfigurieren der Einstellung für die Mindestanzahl von Threads

Sie können diese Einstellung programmgesteuert mit der Methode ThreadPool.SetMinThreads (...) ändern.

In NET Framework legen Sie z. B. diesen Wert in Global.asax.cs in der Methode Application_Start fest:

    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);
    }

Wenn Sie .NET Core verwenden, legen Sie den Wert in Program.cs direkt vor dem Aufruf auf WebApplication.CreateBuilder() fest:

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Hinweis

Der von dieser Methode angegebene Wert ist eine globale Einstellung, die sich auf die gesamte AppDomain auswirkt. Wenn Sie z. B. über eine VM mit vier Kernen verfügen und während der Laufzeit minWorkerThreads und minIoThreads auf 50 pro CPU festlegen möchten, verwenden Sie ThreadPool.SetMinThreads(200, 200).

Sie können die Einstellung für die minimale Anzahl von Threads auch mithilfe der minIoThreadsminWorkerThreads oder im Konfigurationselement <processModel> in Machine.config angeben. 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. Wenn Sie auf diese Weise die Mindestanzahl von Threads festlegen, müssen Sie den Anwendungspool neu starten.

Hinweis

Der von dieser Methode angegebene Wert ist eine Einstellung pro Kern. Wenn Sie z. B. über einen Computer mit vier Kernen verfügen und für minIoThreads zur Laufzeit eine Einstellung von 200 festlegen möchten, verwenden Sie <processModel minIoThreads="50">.

Verwandte Inhalte

• Weitere Informationen finden Sie in anderen häufig gestellten Fragen zu Azure Cache for Redis.