Übersicht über die Zwischenspeicherung in ASP.NET Core

Von Rick Anderson und Kirk Larkin

In-Memory-Caching

Die In-Memory-Zwischenspeicherung verwendet Serverarbeitsspeicher zur Aufbewahrung zwischengespeicherter Daten. Diese Art des Zwischenspeicherns eignet sich für einen einzelnen Server oder für mehrere Server mit Sitzungsaffinität. Die Sitzungsaffinität wird auch als Sticky Sessions bezeichnet. Sitzungsaffinität bedeutet, dass die Anforderungen von einem Client immer an denselben Server zur Verarbeitung weitergeleitet werden.

Weitere Informationen finden Sie unter In-Memory-Zwischenspeicherung in ASP.NET Core und unter Behandeln von Problemen mit der Azure Application Gateway-Sitzungsaffinität.

Verteilter Cache

Verwenden Sie einen verteilten Cache, um Daten im Arbeitsspeicher zu speichern, wenn die App in einer Cloud oder Serverfarm gehostet wird. Der Cache wird von den Servern, die Anforderungen verarbeiten, gemeinsam genutzt. Ein Client kann eine Anforderung übermitteln, die von einem beliebigen Server in der Gruppe verarbeitet wird, wenn zwischengespeicherte Daten für den Client verfügbar sind. ASP.NET Core funktioniert mit verteilten Caches von SQL Server, Redis und NCache.

Weitere Informationen finden Sie unter Verteiltes Zwischenspeichern in ASP.NET Core.

Cache-Taghilfsprogramm

Speichern Sie den Inhalt aus einer MVC-Ansicht oder einer Razor Page-Instanz mit dem Cache-Taghilfsprogramm zwischen. Das Cache-Taghilfsprogramm verwendet die In-Memory-Zwischenspeicherung zum Speichern von Daten.

Weitere Informationen finden Sie unter Cache-Taghilfsprogramm im ASP.NET Core MVC.

Taghilfsprogramm für verteilten Cache

Speichern Sie den Inhalt aus einer MVC-Ansicht oder einer Razor Page-Instanz in verteilten Cloud- oder Webfarmszenarien mit dem Taghilfsprogramm für verteilten Cache zwischen. Das Taghilfsprogramm für verteilten Cache verwendet SQL Server, Redis oder NCache zum Speichern von Daten.

Weitere Informationen finden Sie unter Taghilfsprogramm für verteilten Cache in ASP.NET Core.

Zwischenspeichern von Antworten

Für die Middleware zum Zwischenspeichern von Antworten gilt Folgendes:

• Ermöglicht das Zwischenspeichern von Serverantworten basierend auf HTTP-Cacheheadern. Implementiert die standardmäßige HTTP-Zwischenspeicherungssemantik. Führt die Zwischenspeicherung basierend auf HTTP-Cacheheadern durch – genauso wie Proxys.
• Ist in der Regel nicht vorteilhaft für Benutzeroberflächen-Apps wie Razor Pages, da Browser im Allgemeinen Anforderungsheader festlegen, die das Zwischenspeichern verhindern. Benutzeroberflächen-Apps profitieren von der Ausgabezwischenspeicherung, die in ASP.NET Core 7.0 und höher verfügbar ist. Bei der Ausgabezwischenspeicherung entscheidet die Konfiguration unabhängig von HTTP-Headern, was zwischengespeichert werden soll.
• Dies kann bei öffentlichen GET- oder HEAD API-Anforderungen von Clients von Vorteil sein, wenn die Bedingungen für die Zwischenspeicherung erfüllt sind.

Verwenden Sie zum Testen der Antwortzwischenspeicherung Fiddler oder ein anderes Tool, das Anforderungsheader explizit festlegen kann. Beim Testen der Zwischenspeicherung wird das explizite Festlegen von Headern bevorzugt. Weitere Informationen finden Sie unter Problembehandlung.

Ausgabezwischenspeicherung

Die Middleware für die Ausgabezwischenspeicherung ermöglicht das Zwischenspeichern von HTTP-Antworten. Die Ausgabezwischenspeicherung unterscheidet sich auf folgende Weise vom Zwischenspeichern von Antworten:

• Das Zwischenspeicherungsverhalten kann auf dem Server konfiguriert werden.

  Das Verhalten der Antwortzwischenspeicherung wird durch HTTP-Header definiert. Wenn Sie beispielsweise eine Website über Chrome oder Edge besuchen, sendet der Browser automatisch einen Cache-control: max-age=0-Header. Dieser Header deaktiviert effektiv die Antwortzwischenspeicherung, da der Server die vom Client angegebenen Anweisungen befolgt. Für jede Anforderung wird auch dann eine neue Antwort zurückgegeben, wenn der Server über eine aktuelle zwischengespeicherte Antwort verfügt. Bei der Ausgabezwischenspeicherung überschreibt der Client nicht das Zwischenspeicherungsverhalten, das Sie auf dem Server konfigurieren.

• Das Cachespeichermedium ist erweiterbar.

  Der Arbeitsspeicher wird standardmäßig verwendet. Die Antwortzwischenspeicherung ist auf den Arbeitsspeicher beschränkt.

• Sie können ausgewählte Cacheeinträge programmgesteuert als ungültig festlegen.

  Die Abhängigkeit der Antwortzwischenspeicherung von HTTP-Headern lässt Ihnen nur wenige Optionen zum Aufheben der Gültigkeit von Cacheeinträgen.

• Die Ressourcensperrung verringert das Risiko von Cache Stampede und Thundering Herd Problem.

  Cache Stampede tritt auf, wenn ein häufig verwendeter Cacheeintrag widerrufen wird und zu viele Anforderungen versuchen, denselben Cacheeintrag gleichzeitig neu aufzufüllen. Thundering Herd ist ähnlich: eine Flut von Anforderungen für dieselbe Antwort, die sich noch nicht in einem Cacheeintrag befindet. Die Ressourcensperre sorgt dafür, dass alle Anforderungen für eine bestimmte Antwort auf die erste Anforderung warten, um den Cache zu füllen. Die Antwortzwischenspeicherung verfügt über kein Feature zum Sperren von Ressourcen.

• Die erneute Cacheüberprüfung minimiert die Bandbreitennutzung.

  Erneute Cacheüberprüfung bedeutet, dass der Server anstelle eines zwischengespeicherten Antworttexts einen 304 Not Modified-HTTP-Statuscode zurückgeben kann. Dieser Statuscode informiert den Client darüber, dass die Antwort auf die Anforderung mit der zuvor empfangenen Antwort identisch ist. Bei der Antwortzwischenspeicherung wird keine erneute Cacheüberprüfung durchgeführt.