Häufig gestellte Fragen zur Azure Managed Redis-Verwaltung

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

Wann sollte ich den nicht für TLS/SSL bestimmten Port für die Verbindungsherstellung mit Redis aktivieren?

Die Verwendung von TLS wird als bewährte Methode für nahezu alle Redis-Anwendungsfälle empfohlen. Die Option zum Herstellen einer Verbindung ohne TLS ist für Abwärtskompatibilitätszwecke enthalten.

Welche Best Practices gelten für die Produktion?

• 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.
• Redis funktioniert am besten mit kleineren Werten, deshalb sollten Sie die Aufteilung großer Daten in mehrere Schlüssel erwägen. In der 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 vermeiden.
• 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

• Beachten Sie, dass Redis ein In-Memory -Datenspeicher ist. Weitere Informationen finden Sie unter Problembehandlung bei Datenverlust in Azure Managed Redis, damit Sie sich bewusst sind, 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

• Lesen Sie Leistungstests mit Azure Managed Redis für Beispielbenchmarks und Anweisungen zum Ausführen Ihrer eigenen Leistungstests auf Azure Managed Redis.

Was muss bei der Verwendung gängiger Redis-Befehle beachtet 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. Jeder Redis-Shard ist ein Single-Thread und verarbeitet einen Befehl nach dem anderen. 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 jeden mit einem anderen Satz von Timeout- und Wiederholungswerten, wie im vorherigen Abschnitt "Was tun die StackExchange.Redis-Konfigurationsoptionen tun" .

Wie kann ich die Leistung meines Caches messen und testen?

• 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 .
• Lesen Sie Leistungstests mit Azure Managed Redis für Beispielbenchmarks und Anweisungen zum Ausführen Ihrer eigenen Leistungstests auf Azure Managed Redis.

Wichtige Details zum Threadpool-Wachstum

Der CLR-Threadpool verfügt über zwei Arten von Threads : Worker- und E/A-Abschlussportthreads (IOCP).

• 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 injiziert, auf einen Thread pro 500 Millisekunden. Wenn bei Ihrem System eine Arbeitsspitze auftritt, 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 der Beschäftigt-Threads größer als Min-Threads ist, zahlen Sie wahrscheinlich eine Verzögerung von 500 ms, bevor die Anwendung den Netzwerkdatenverkehr verarbeitet. Zudem wird ein vorhandener Thread nach einer Leerlaufdauer von mehr als 15 Sekunden bereinigt, und der Zyklus aus Wachstum und Schrumpfung kann sich wiederholen.

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

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 gezeigt, sehen Sie, dass für IOCP-Thread sechs Beschäftigt-Threads vorhanden sind und das System so konfiguriert ist, dass vier Mindestthreads zulässig sind. In diesem Fall würde der Client zwei Verzögerungen von 500 ms sehen, da 6 > 4.

Hinweis

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

Empfehlung

Es wird empfohlen, dass Kunden den minimalen Konfigurationswert für IOCP- und WORKER-Threads auf etwas festlegen, das größer als der Standardwert ist. Wir können diesem Wert keine Anleitungen für eine Größe zuweisen, da der richtige Wert für eine Anwendung für eine andere Anwendung zu hoch oder niedrig sein kann. Diese Einstellung kann sich auch auf die Leistung anderer Teile komplizierter Anwendungen auswirken. Jeder Kunde muss diese Einstellung an ihre spezifischen Anforderungen anpassen. 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 mithilfe der ThreadPool.SetMinThreads (...) -Methode in .NET Framework- und .NET Core-Anwendungen zu ändern.

In NET Framework legen Sie sie beispielsweise in Global.asax.cs der Application_Start Methode fest:

```csharp
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 sie direkt Program.csvor dem Aufruf an WebApplication.CreateBuilder():

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

Hinweis

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

Es ist auch möglich, die Mindestthread-Einstellung mithilfe der minIoThreads Oder minWorkerThreadsKonfigurationseinstellung 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 dies auf diese Weise festlegen, müssen Sie den Anwendungspool neu starten.

Hinweis

Der in diesem Konfigurationselement angegebene Wert ist eine Einstellung pro Kern. Wenn Sie z. B. über einen Vierkerncomputer verfügen und ihre minIoThreads Einstellung zur Laufzeit 200 sein soll, verwenden Sie <processModel minIoThreads="50">.

Aktivieren der 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:

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

Überlegungen zur Leistung im Zusammenhang mit Verbindungen

Verschiedene SKUs können unterschiedliche Grenzwerte für Clientverbindungen, Arbeitsspeicher und Bandbreite aufweisen. Während jede Cachegröße bis zu einer gewissen Anzahl von Verbindungen zulässt, weist jede Verbindung mit Redis mehr Aufwand auf. 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 verschiedenen Verbindungsgrenzwerten für die einzelnen Ebenen finden Sie unter Azure Managed Redis-Preise.

Verwandte Inhalte

• Erfahren Sie mehr über weitere häufig gestellte Fragen zu Azure Managed Redis.

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

Die Verwendung von TLS wird als bewährte Methode für nahezu alle Redis-Anwendungsfälle empfohlen. Die Option zum Herstellen einer Verbindung ohne TLS ist für Abwärtskompatibilitätszwecke enthalten.

• 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.
• Redis funktioniert am besten mit kleineren Werten, deshalb sollten Sie die Aufteilung großer Daten in mehrere Schlüssel erwägen. In der 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 vermeiden.
• 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

• Beachten Sie, dass Redis ein In-Memory -Datenspeicher ist. Weitere Informationen finden Sie unter Problembehandlung bei Datenverlust in Azure Managed Redis, damit Sie sich bewusst sind, 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

• Lesen Sie Leistungstests mit Azure Managed Redis für Beispielbenchmarks und Anweisungen zum Ausführen Ihrer eigenen Leistungstests auf Azure Managed Redis.

• 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. Jeder Redis-Shard ist ein Single-Thread und verarbeitet einen Befehl nach dem anderen. 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 jeden mit einem anderen Satz von Timeout- und Wiederholungswerten, wie im vorherigen Abschnitt "Was tun die StackExchange.Redis-Konfigurationsoptionen tun" .

• 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 .
• Lesen Sie Leistungstests mit Azure Managed Redis für Beispielbenchmarks und Anweisungen zum Ausführen Ihrer eigenen Leistungstests auf Azure Managed Redis.

Der CLR-Threadpool verfügt über zwei Arten von Threads : Worker- und E/A-Abschlussportthreads (IOCP).

• 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 injiziert, auf einen Thread pro 500 Millisekunden. Wenn bei Ihrem System eine Arbeitsspitze auftritt, 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 der Beschäftigt-Threads größer als Min-Threads ist, zahlen Sie wahrscheinlich eine Verzögerung von 500 ms, bevor die Anwendung den Netzwerkdatenverkehr verarbeitet. Zudem wird ein vorhandener Thread nach einer Leerlaufdauer von mehr als 15 Sekunden bereinigt, und der Zyklus aus Wachstum und Schrumpfung kann sich wiederholen.

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

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 gezeigt, sehen Sie, dass für IOCP-Thread sechs Beschäftigt-Threads vorhanden sind und das System so konfiguriert ist, dass vier Mindestthreads zulässig sind. In diesem Fall würde der Client zwei Verzögerungen von 500 ms sehen, da 6 > 4.

Hinweis

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

Empfehlung

Es wird empfohlen, dass Kunden den minimalen Konfigurationswert für IOCP- und WORKER-Threads auf etwas festlegen, das größer als der Standardwert ist. Wir können diesem Wert keine Anleitungen für eine Größe zuweisen, da der richtige Wert für eine Anwendung für eine andere Anwendung zu hoch oder niedrig sein kann. Diese Einstellung kann sich auch auf die Leistung anderer Teile komplizierter Anwendungen auswirken. Jeder Kunde muss diese Einstellung an ihre spezifischen Anforderungen anpassen. 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 mithilfe der ThreadPool.SetMinThreads (...) -Methode in .NET Framework- und .NET Core-Anwendungen zu ändern.

In NET Framework legen Sie sie beispielsweise in Global.asax.cs der Application_Start Methode fest:

```csharp
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 sie direkt Program.csvor dem Aufruf an WebApplication.CreateBuilder():

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

Hinweis

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

Es ist auch möglich, die Mindestthread-Einstellung mithilfe der minIoThreads Oder minWorkerThreadsKonfigurationseinstellung 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 dies auf diese Weise festlegen, müssen Sie den Anwendungspool neu starten.

Hinweis

Der in diesem Konfigurationselement angegebene Wert ist eine Einstellung pro Kern. Wenn Sie z. B. über einen Vierkerncomputer verfügen und ihre minIoThreads Einstellung zur Laufzeit 200 sein soll, verwenden Sie <processModel minIoThreads="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:

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

Verschiedene SKUs können unterschiedliche Grenzwerte für Clientverbindungen, Arbeitsspeicher und Bandbreite aufweisen. Während jede Cachegröße bis zu einer gewissen Anzahl von Verbindungen zulässt, weist jede Verbindung mit Redis mehr Aufwand auf. 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 verschiedenen Verbindungsgrenzwerten für die einzelnen Ebenen finden Sie unter Azure Managed Redis-Preise.

Verwandte Inhalte

• Erfahren Sie mehr über weitere häufig gestellte Fragen zu Azure Managed Redis.