Bearbeiten

Freigeben über


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

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

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

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).

Hinweis

Bei neuen Azure Cache for Redis-Instanzen ist der nicht für TLS bestimmte Port standardmäßig deaktiviert. Wenn Ihr Client keine TLS-Unterstützung bietet, müssen Sie den nicht für TLS bestimmten Port gemäß den Anweisungen im Abschnitt Zugriffsports des Artikels Konfigurieren eines Caches in Azure Cache for Redis aktivieren.

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? .

Welche Best Practices gelten für die Produktion?

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.

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. 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.

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 .
  • 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

Hinweis

Führen Sie zunächst den oben gezeigten SET-Test aus, um den Cache zu füllen.

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

Wichtige Details zum Threadpool-Wachstum

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.

Hinweis

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

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.

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:

Überlegungen zur Leistung im Zusammenhang mit Verbindungen

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.