Häufig gestellte Fragen zur Cache-Verwaltung

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

Wie kann ich die Leistung meines Caches messen und testen?

• Verwenden Sie diese Option redis-benchmark.exe , um einen Lasttest für Ihren Redis-Server durchzuführen. Verwenden Sie diese Option redis-benchmark.exe , um ein Gefühl für den möglichen Durchsatz zu bekommen, bevor Sie Ihre eigenen Leistungstests schreiben.
• Verwenden Sie diese Option redis-cli , um den Cache mit dem INFO Befehl 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 --tls Parameter 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 -p Parameter, um diese Einstellung zu überschreiben, wenn Ihr Cache den SSL/TLS-Port 6380 oder den Port 10000der Enterprise-Ebene 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 Virtuelle empfangsseitige Skalierung in 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 Sie können Ihre Metriken auch mit den Tools Ihrer Wahl herunterladen und überprüfen .
• Wenn Ihre Auslastung eine hohe Speicherfragmentierung verursacht, skalieren Sie auf eine größere Cachegröße hoch.

Die folgenden Beispiele zeigen, wie redis-benchmark.exeSie . Führen Sie diese Befehle von einer VM aus, die sich in derselben Region wie Ihr Cache befindet, um genaue Ergebnisse zu erhalten.

Testen Sie zunächst pipelined-Anfragen SET 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 kann ich Server-GC aktivieren, um mehr Durchsatz auf dem Client zu erzielen, wenn ich StackExchange.Redis verwende?

Durch das Aktivieren der Garbage Collection (Garbage Collection, GC) des Servers kann der Client optimiert und eine bessere Leistung und ein besserer Durchsatz erzielt werden, wenn Sie StackExchange.Redis verwenden. 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-TLS/SSL-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 --tls Option für Redis-Tools wie redis-cliverwenden. 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 KEYS Befehl ausgeben, verarbeitet Redis nachfolgende Befehle erst, wenn die Verarbeitung des KEYS Befehls abgeschlossen ist.

  Die redis.io Website 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 erfordert, können Sie die ConnectionTimeoutWerte für und dann für die Wiederholung anpassen und die Wiederholungslogik anpassen. Aus der Perspektive eines Redis-Servers bieten kleinere Schlüsselwerte eine bessere 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?

Für jeden Azure Cache for Redis-Tarif gelten unterschiedliche Grenzwerte für Clientverbindungen, Arbeitsspeicher und Bandbreite. Während jede Cache-Größe bis zu einer bestimmten Anzahl von Verbindungen zulässt, ist jede Verbindung zu Redis mit einem zugehörigen Overhead verbunden. Ein Beispiel für einen solchen Overhead ist die CPU- und Speicherauslastung 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 Auslastung durch den Verbindungsoverhead und die Auslastung durch Clientvorgänge die Kapazität des Systems übersteigt, kann es zu Kapazitätsproblemen im Cache kommen, selbst wenn Sie den Verbindungsgrenzwert für die aktuelle Cachegröße nicht überschreiten.

Weitere Informationen zu den Verbindungsgrenzwerten für die einzelnen Tarife 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 Vereinbarung zum Servicelevel (Service Level Agreement, 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 Azure Redis-Instanzen im Premium-Tarif, um die Netzwerklatenz und den Durchsatz zu verbessern, da sie über eine bessere Hardware für CPU und Netzwerk verfügen.

Best Practices für StackExchange.Redis

• Legen Sie den Wert auf false fest AbortConnect , und lassen Sie die ConnectionMultiplexer 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 connectTimeout von 5 Sekunden. Dieses Intervall gibt StackExchange.Redis genügend Zeit, um die Verbindung wiederherzustellen, wenn ein Netzwerkfehler auftritt.
• Beachten Sie die Leistungseinbußen, die mit den verschiedenen von Ihnen ausgeführten Vorgängen verbunden sind. Beispielsweise ist der KEYS -Befehl ein O(n)-Vorgang und sollte vermieden werden. Die redis.io Website 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 ThreadPool der Common Language Runtime (CLR) verfügt über zwei Arten von Threads: Worker und I/O Completion Port (IOCP).

• 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 bei Bedarf neue Arbeitsthreads oder E/A-Abschlussthreads ohne Drosselung bereit, bis die Einstellung für jeden minimum Threadtyp erreicht ist. Standardmäßig entspricht die minimale Anzahl von Threads der Anzahl von Prozessoren in einem System.

Sobald die Anzahl der vorhandenen ausgelasteten Threads die Anzahl der minimum Threads erreicht, drosselt der ThreadPool die Rate, mit der neue Threads eingefügt werden, auf einen Thread pro 500 Millisekunden.

Wenn Ihr System einen Arbeitsstoß erhält, der einen IOCP Thread benötigt, wird dieser in der Regel schnell verarbeitet. Wenn der Burst jedoch größer als die konfigurierte minimum Einstellung ist, kommt es zu einer Verzögerung bei der Verarbeitung eines Teils der Arbeit, da der ThreadPool auf eine von zwei Möglichkeiten wartet:

• Ein vorhandener Thread wird frei, um die Arbeitsvorgänge zu verarbeiten.
• Kein vorhandener Thread wird für 500 ms frei, sodass ein neuer Thread erstellt wird.

Wenn die Anzahl der Threads größer als Busy die Anzahl der Min Threads ist, tritt grundsätzlich eine Verzögerung von 500 ms auf, bevor die Anwendung den Netzwerkdatenverkehr verarbeitet. Außerdem wird ein vorhandener Thread, der länger als 15 Sekunden im Leerlauf bleibt, bereinigt, und dieser Zyklus von Wachstum und Schrumpfung kann sich wiederholen.

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

StackExchange.Redis kann Timeouts erreichen, wenn das Wachstum eines oder IOCP von WORKER Threads gedrosselt wird.

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 or .300 Testen und optimieren Sie dann nach Bedarf.

Konfigurieren der Einstellung für die Mindestanzahl von Threads

Sie können diese Einstellung programmgesteuert ändern, indem Sie die ThreadPool.SetMinThreads (...) Methode verwenden.

In NET Framework legen Sie z. B. diesen Wert in Global.asax.cs in der Application_Start Methode 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():

    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 einen minWorkerThreads Wert von und auf 50 pro CPU festlegen minIoThreads möchten, verwenden Sie ThreadPool.SetMinThreads(200, 200).

Es ist auch möglich, die Einstellung für die minimale Anzahl von Threads mithilfe der minIoThreadsminWorkerThreads or unter dem <processModel> Konfigurationselement in Machine.configanzugeben. 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, da 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 zur minIoThreads 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.

• Verwenden Sie diese Option redis-benchmark.exe , um einen Lasttest für Ihren Redis-Server durchzuführen. Verwenden Sie diese Option redis-benchmark.exe , um ein Gefühl für den möglichen Durchsatz zu bekommen, bevor Sie Ihre eigenen Leistungstests schreiben.
• Verwenden Sie diese Option redis-cli , um den Cache mit dem INFO Befehl 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 --tls Parameter 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 -p Parameter, um diese Einstellung zu überschreiben, wenn Ihr Cache den SSL/TLS-Port 6380 oder den Port 10000der Enterprise-Ebene 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 Virtuelle empfangsseitige Skalierung in 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 Sie können Ihre Metriken auch mit den Tools Ihrer Wahl herunterladen und überprüfen .
• Wenn Ihre Auslastung eine hohe Speicherfragmentierung verursacht, skalieren Sie auf eine größere Cachegröße hoch.

Die folgenden Beispiele zeigen, wie redis-benchmark.exeSie . Führen Sie diese Befehle von einer VM aus, die sich in derselben Region wie Ihr Cache befindet, um genaue Ergebnisse zu erhalten.

Testen Sie zunächst pipelined-Anfragen SET 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

Durch das Aktivieren der Garbage Collection (Garbage Collection, GC) des Servers kann der Client optimiert und eine bessere Leistung und ein besserer Durchsatz erzielt werden, wenn Sie StackExchange.Redis verwenden. 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 --tls Option für Redis-Tools wie redis-cliverwenden. 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 KEYS Befehl ausgeben, verarbeitet Redis nachfolgende Befehle erst, wenn die Verarbeitung des KEYS Befehls abgeschlossen ist.

  Die redis.io Website 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 erfordert, können Sie die ConnectionTimeoutWerte für und dann für die Wiederholung anpassen und die Wiederholungslogik anpassen. Aus der Perspektive eines Redis-Servers bieten kleinere Schlüsselwerte eine bessere 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?

Für jeden Azure Cache for Redis-Tarif gelten unterschiedliche Grenzwerte für Clientverbindungen, Arbeitsspeicher und Bandbreite. Während jede Cache-Größe bis zu einer bestimmten Anzahl von Verbindungen zulässt, ist jede Verbindung zu Redis mit einem zugehörigen Overhead verbunden. Ein Beispiel für einen solchen Overhead ist die CPU- und Speicherauslastung 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 Auslastung durch den Verbindungsoverhead und die Auslastung durch Clientvorgänge die Kapazität des Systems übersteigt, kann es zu Kapazitätsproblemen im Cache kommen, selbst wenn Sie den Verbindungsgrenzwert für die aktuelle Cachegröße nicht überschreiten.

Weitere Informationen zu den Verbindungsgrenzwerten für die einzelnen Tarife 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 Vereinbarung zum Servicelevel (Service Level Agreement, 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 Azure Redis-Instanzen im Premium-Tarif, um die Netzwerklatenz und den Durchsatz zu verbessern, da sie über eine bessere Hardware für CPU und Netzwerk verfügen.

Best Practices für StackExchange.Redis

• Legen Sie den Wert auf false fest AbortConnect , und lassen Sie die ConnectionMultiplexer 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 connectTimeout von 5 Sekunden. Dieses Intervall gibt StackExchange.Redis genügend Zeit, um die Verbindung wiederherzustellen, wenn ein Netzwerkfehler auftritt.
• Beachten Sie die Leistungseinbußen, die mit den verschiedenen von Ihnen ausgeführten Vorgängen verbunden sind. Beispielsweise ist der KEYS -Befehl ein O(n)-Vorgang und sollte vermieden werden. Die redis.io Website 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 ThreadPool der Common Language Runtime (CLR) verfügt über zwei Arten von Threads: Worker und I/O Completion Port (IOCP).

• 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 bei Bedarf neue Arbeitsthreads oder E/A-Abschlussthreads ohne Drosselung bereit, bis die Einstellung für jeden minimum Threadtyp erreicht ist. Standardmäßig entspricht die minimale Anzahl von Threads der Anzahl von Prozessoren in einem System.

Sobald die Anzahl der vorhandenen ausgelasteten Threads die Anzahl der minimum Threads erreicht, drosselt der ThreadPool die Rate, mit der neue Threads eingefügt werden, auf einen Thread pro 500 Millisekunden.

Wenn Ihr System einen Arbeitsstoß erhält, der einen IOCP Thread benötigt, wird dieser in der Regel schnell verarbeitet. Wenn der Burst jedoch größer als die konfigurierte minimum Einstellung ist, kommt es zu einer Verzögerung bei der Verarbeitung eines Teils der Arbeit, da der ThreadPool auf eine von zwei Möglichkeiten wartet:

• Ein vorhandener Thread wird frei, um die Arbeitsvorgänge zu verarbeiten.
• Kein vorhandener Thread wird für 500 ms frei, sodass ein neuer Thread erstellt wird.

Wenn die Anzahl der Threads größer als Busy die Anzahl der Min Threads ist, tritt grundsätzlich eine Verzögerung von 500 ms auf, bevor die Anwendung den Netzwerkdatenverkehr verarbeitet. Außerdem wird ein vorhandener Thread, der länger als 15 Sekunden im Leerlauf bleibt, bereinigt, und dieser Zyklus von Wachstum und Schrumpfung kann sich wiederholen.

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

StackExchange.Redis kann Timeouts erreichen, wenn das Wachstum eines oder IOCP von WORKER Threads gedrosselt wird.

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 or .300 Testen und optimieren Sie dann nach Bedarf.

Konfigurieren der Einstellung für die Mindestanzahl von Threads

Sie können diese Einstellung programmgesteuert ändern, indem Sie die ThreadPool.SetMinThreads (...) Methode verwenden.

In NET Framework legen Sie z. B. diesen Wert in Global.asax.cs in der Application_Start Methode 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():

    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 einen minWorkerThreads Wert von und auf 50 pro CPU festlegen minIoThreads möchten, verwenden Sie ThreadPool.SetMinThreads(200, 200).

Es ist auch möglich, die Einstellung für die minimale Anzahl von Threads mithilfe der minIoThreadsminWorkerThreads or unter dem <processModel> Konfigurationselement in Machine.configanzugeben. 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, da 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 zur minIoThreads 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.