Freigeben über

Lokaler Cache in Azure App Service

Tipp

Sie können Microsoft Copilot auch in Azure folgende Fragen stellen:

  • Wie funktioniert ein lokaler Cache in Azure App Service?
  • Was sind die Vorteile der Verwendung eines lokalen Caches in Azure App Service?
  • Was sind die Einschränkungen der Verwendung eines lokalen Caches in Azure App Service?

Um Copilot in Azure zu finden, wählen Sie auf der Azure-Portalsymbolleiste"Copilot" aus.

Azure App Service-Inhalte werden in Azure Storage gespeichert und als dauerhafte Inhaltsfreigabe verfügbar gemacht. Dieses Design funktioniert mit verschiedenen Apps und hat die folgenden Attribute:

  • Der Inhalt wird für mehrere VM-Instanzen der App freigegeben.
  • Der Inhalt ist dauerhaft, und das Ausführen von Apps kann ihn ändern.
  • Protokolldateien und Diagnosedatendateien sind unter demselben freigegebenen Inhaltsordner verfügbar.
  • Durch das Veröffentlichen neuer Inhalte wird der Inhaltsordner direkt aktualisiert. Sie können denselben Inhalt sofort über die Website des Quellcodeverwaltungs-Managers (Source Control Manager, auch kudu genannt) und die ausgeführte App anzeigen. Einige Technologien (z. B. ASP.NET) initiieren jedoch möglicherweise einen App-Neustart bei bestimmten Dateiänderungen, um den neuesten Inhalt zu laden.

Obwohl viele Apps eine oder mehrere dieser Features verwenden, benötigen einige Apps einen leistungsfähigen, schreibgeschützten Inhaltsspeicher, aus dem sie mit hoher Verfügbarkeit ausgeführt werden können. Solche Apps können von der Ausführung mit einem lokalen Cache auf der VM-Instanz profitieren.

Das feature "Lokaler Cache" in Azure App Service bietet eine Webrollenansicht Ihrer Inhalte. Dabei handelt es sich um einen Cache Ihres Speicherinhalts mit „write but discard“-Prinzip, der beim lokalen Start asynchron erstellt wird. Wenn der Cache bereit ist, wird die Site zur Ausführung mit dem zwischengespeicherten Inhalt umgeschaltet.

Apps, die mit einem lokalen Cache arbeiten, profitieren auf folgende Weise:

  • Sie sind immun gegen Latenzen im Zusammenhang mit dem Zugriff auf Inhalte in Azure Storage.
  • Probleme beim Herstellen einer Verbindung mit dem Speicher wirken sich nicht auf sie aus, da die schreibgeschützte Kopie lokal zwischengespeichert wird.
  • Sie erleben weniger App-Neustarts durch Änderungen an der Speicherfreigabe.

Hinweis

Das Feature für den lokalen Cache wird in Funktions-Apps oder containerisierten App Service-Apps wie in Windows-Containern oder in integrierten oder benutzerdefinierten Linux-Containern nicht unterstützt. Eine Version des Features, das für diese App-Typen verfügbar ist, ist der App-Cache.

Das feature für den lokalen Cache wird auch in den Preisstufen F1 und D1 des App-Diensts nicht unterstützt.

So ändert ein lokaler Cache das Verhalten von App Service

Durch das Konfigurieren eines lokalen Caches werden die folgenden Änderungen verursacht:

  • D:\home verweist nun auf den lokalen Cache, der beim Starten der App auf der VM-Instanz erstellt wird. D:\local zeigt weiterhin auf den temporären, VM-spezifischen Speicher.

  • Der lokale Cache enthält eine einmalige Kopie der /site Und /siteextensions Ordner aus dem freigegebenen Inhaltsspeicher. Diese Ordner befinden sich bei D:\home\site und D:\home\siteextensions. Diese Dateien werden beim Starten der App in den lokalen Cache kopiert.

    Die Größe dieser beiden Ordner ist standardmäßig auf 1 GB beschränkt, Sie können sie jedoch auf 2 GB erhöhen. Wenn die Cachegröße zunimmt, dauert es länger, bis der Cache geladen wird. Wenn Sie den grenzwert für den lokalen Cache auf 2 GB erhöhen und die kopierten Dateien diese maximale Größe überschreiten, ignoriert App Service im Hintergrund den lokalen Cache und liest aus der Remotedateifreigabe.

    Von Bedeutung

    Wenn die kopierten Dateien den definierten Größengrenzwert für den lokalen Cache überschreiten oder wenn kein Grenzwert definiert ist, können Bereitstellungs- und Swapvorgänge mit einem Fehler fehlschlagen. Ausführliche Informationen finden Sie in den häufig gestellten Fragen zu Größenbeschränkungen weiter unten in diesem Artikel.

  • Der lokale Cache ist sowohl les- als auch schreibfähig. Änderungen werden jedoch verworfen, wenn die App zwischen virtuellen Computern wechselt oder neu gestartet wird. Verwenden Sie nicht den lokalen Cache zum Speichern unternehmenskritischer Daten.

  • D:\home\LogFiles und D:\home\Data enthalten Protokolldateien und App-Daten. Diese Ordner werden lokal auf der VM-Instanz gespeichert und regelmäßig in den freigegebenen Inhaltsspeicher kopiert. Obwohl Apps Protokolldateien und Daten speichern können, indem sie in diese Ordner schreiben, wird der Kopiervorgang nach dem Best-Effort-Prinzip durchgeführt. Protokolldateien und Daten gehen möglicherweise verloren, wenn eine VM-Instanz plötzlich nicht mehr reagiert.

  • Die Best-Effort-Kopie wirkt sich auf das Protokollstreaming aus. Möglicherweise beobachten Sie bis zu einer Minutenverzögerung in gestreamten Protokollen.

  • In dem freigegebenen Inhaltsspeicher ändert sich die Ordnerstruktur für LogFiles und Data bei Apps, die einen lokalen Cache verwenden. Es gibt jetzt Unterordner mit Namen, die aus einem eindeutigen Bezeichner und einem Zeitstempel bestehen. Jeder Unterordner entspricht einer VM-Instanz, in der die App ausgeführt wird.

  • Andere Ordner in D:\home verbleiben im lokalen Cache und werden nicht in den gemeinsamen Inhaltsspeicher kopiert.

  • Bei der App-Bereitstellung über eine unterstützte Methode erfolgt die Veröffentlichung direkt im permanenten freigegebenen Inhaltsspeicher. Um die Ordner D:\home\site und D:\home\siteextensions im lokalen Cache zu aktualisieren, müssen Sie die App neu starten. Einen nahtlosen Lebenszyklus finden Sie im Abschnitt zu bewährten Methoden weiter unten in diesem Artikel.

  • Die Standardinhaltsansicht der SCM-Website spiegelt weiterhin den freigegebenen Inhaltsspeicher wider.

Hinweis

Wenn Sie Java (Java SE, Tomcat oder JBoss EAP) verwenden, werden standardmäßig die Java-Artefakte (.jar-, WAR- und EAR-Dateien) lokal in den Worker kopiert. Wenn Ihre Java-Anwendung auf schreibgeschützte zusätzliche Dateien zugreifen muss, stellen Sie JAVA_COPY_ALL auf true ein, sodass diese Dateien ebenfalls kopiert werden. Wenn ein lokaler Cache aktiviert ist, hat er Vorrang vor diesem Java-spezifischen Verhalten.

Methoden zum Aktivieren eines lokalen Caches

Sie konfigurieren einen lokalen Cache mithilfe einer Kombination aus reservierten App-Einstellungen. Sie können diese App-Einstellungen mit einer der folgenden Methoden festlegen.

Konfigurieren eines lokalen Caches mithilfe des Azure-Portals

Aktivieren Sie einen lokalen Cache auf Web-App-Basis, indem Sie diese App-Einstellung hinzufügen: WEBSITE_LOCAL_CACHE_OPTION = Always.

Konfigurieren eines lokalen Caches mithilfe von Azure Resource Manager

{
    "apiVersion": "2015-08-01",
    "type": "config",
    "name": "appsettings",
    "dependsOn": [
        "[resourceId('Microsoft.Web/sites/', variables('siteName'))]"
    ],

    "properties": {
        "WEBSITE_LOCAL_CACHE_OPTION": "Always",
        "WEBSITE_LOCAL_CACHE_SIZEINMB": "1000"
    }
}

Ändern der Größeneinstellung in einem lokalen Cache

Standardmäßig beträgt die lokale Cachegröße 1 GB. Diese Größe umfasst die aus dem Inhaltsspeicher kopierten Ordner /site und /siteextensions. Sie enthält auch alle lokal generierten Protokolle und Datenordner.

Verwenden Sie die App-Einstellung WEBSITE_LOCAL_CACHE_SIZEINMB, um diesen Grenzwert zu erhöhen. Sie können die Größe pro App auf 2 GB (2.000 MB) erhöhen. Beachten Sie, dass eine größere Cachegröße die Zeit zum Laden des Caches erhöht.

Bewährte Methoden für die Verwendung eines lokalen Caches

Wir empfehlen die Verwendung eines lokalen Caches in Verbindung mit der Funktion Stagingumgebungen.

Der folgende Prozess stellt die bewährten Methoden für die Verwendung eines lokalen Caches dar:

  1. Fügen Sie die persistente App-Einstellung WEBSITE_LOCAL_CACHE_OPTION mit dem Wert Always zu Ihrem Produktionsslot hinzu. Wenn Sie WEBSITE_LOCAL_CACHE_SIZEINMB verwenden, markieren Sie diese Einstellung auch als dauerhafte Einstellung für den Produktionsslot.

  2. Erstellen Sie einen Stagingslot, und veröffentlichen Sie ihn. In der Regel legen Sie den Stagingplatz nicht auf die Verwendung eines lokalen Caches fest. Dadurch wird ein nahtloser Build-/Bereitstellungs-/Testlebenszyklus ermöglicht und gleichzeitig lokale Cachevorteile für den Produktionsplatz bereitgestellt.

  3. Testen Sie Ihre Website im Staging-Slot.

  4. Wenn Sie bereit sind, führen Sie einen Swap-Vorgang zwischen Staging- und Produktionsslot aus.

Fixierte Einstellungen sind an den Slot gebunden. Wenn der Staging-Slot in die Produktion verschoben wird, übernimmt er die App-Einstellungen des lokalen Caches. Der gerade getauschte Produktionsslot wird nach ein paar Minuten mit dem lokalen Cache ausgeführt und wird während des Slot-Warmups aufgewärmt. Nachdem der Tausch abgeschlossen ist, wird Ihr Produktionsslot mit dem lokalen Cache ausgeführt.

Häufig gestellte Fragen

Was geschieht, wenn ich den Größengrenzwert für den lokalen Cache überschreitet?

Wenn die kopierten Dateien den Größengrenzwert für den lokalen Cache überschreiten, wird die App auf das Lesen aus der Remotefreigabe zurückgesetzt. In der folgenden Tabelle sind die Details aufgeführt.

Größe des lokalen Caches Kopierte Dateien Ergebnis
≤ 2 GB ≤ größe des lokalen Caches Liest aus dem lokalen Cache.
≤ 2 GB > Lokale Cachegröße Liest aus der Remotefreigabe.

Bereitstellungs- und Swap-Vorgänge können mit einem Fehler fehlschlagen.

Wie kann ich feststellen, ob meine App von einem lokalen Cache profitieren kann?

Ein lokaler Cache eignet sich gut, wenn alle diese Bedingungen gelten:

  • Ihre App erfordert einen leistungsfähigen, zuverlässigen Inhaltsspeicher.
  • Ihre App verwendet den Inhaltsspeicher nicht zum Schreiben kritischer Daten zur Laufzeit.
  • Die Gesamtgröße beträgt weniger als 2 GB.

Um die Gesamtgröße Ihrer /site Und /siteextensions Ordner zu überprüfen, können Sie die Websiteerweiterung Azure Web Apps Disk Usage verwenden.

Wie kann ich feststellen, ob meine Website zu einem lokalen Cache gewechselt wurde?

Wenn Sie einen lokalen Cache mit Staging-Umgebungen verwenden, wird der Tauschvorgang erst abgeschlossen, wenn der lokale Cache aufgewärmt ist. Um zu überprüfen, ob Ihre Website gegen den lokalen Cache läuft, überprüfen Sie die Umgebungsvariable WEBSITE_LOCALCACHE_READY des Arbeitsprozesses. Informationen zum Überprüfen dieser Variablen über mehrere Instanzen hinweg finden Sie in den Kudu-Anweisungen für die Umgebungsvariable des Arbeitsprozesses.

Warum spiegelt meine App keine neu veröffentlichten Änderungen wider?

Wenn Ihre App einen lokalen Cache verwendet, müssen Sie die Website neu starten, um die neuesten Änderungen zu laden. Wenn Sie Änderungen nicht direkt an Ihrer Produktionswebsite veröffentlichen möchten, sollten Sie Bereitstellungsplätze wie im vorherigen Abschnitt zu bewährten Methoden beschrieben verwenden.

Hinweis

Die Option "Aus dem Paket ausführen" ist nicht mit der lokalen Cache-Funktion kompatibel.

Wo befinden sich meine Protokolle?

Wenn Sie einen lokalen Cache verwenden, ändert sich die Struktur Ihrer Protokoll- und Datenordner geringfügig. Die Unterordner sind jetzt unter einem Ordner geschachtelt, der mit dem eindeutigen VM-Bezeichner und einem Zeitstempel benannt ist. Jeder dieser Ordner entspricht der VM-Instanz, in der die App ausgeführt wird.

Warum wird meine App immer noch neu gestartet, wobei ein lokaler Cache aktiviert ist?

Ein lokaler Cache trägt dazu bei, speicherbezogene App-Neustarts zu verhindern. Ihre App kann jedoch während geplanter Infrastrukturupgrades auf dem virtuellen Computer möglicherweise noch neu gestartet werden. Insgesamt sollten Sie weniger Neustarts beobachten, wobei ein lokaler Cache aktiviert ist.

Schließt ein lokaler Cache alle Verzeichnisse aus, die auf das schnellere lokale Laufwerk kopiert werden?

Während des Kopiervorgangs wird jeder benannte repository Ordner ausgeschlossen. Dieses Verhalten ist in Szenarien hilfreich, in denen Ihre Websiteinhalte ein Quellcodeverwaltungs-Repository enthalten, das Sie nicht für tägliche Vorgänge benötigen.

Wie lösche ich die lokalen Cacheprotokolle nach einem Standortverwaltungsvorgang?

Um die lokalen Cacheprotokolle zu leeren, beenden Sie die App, und starten Sie sie neu. Diese Aktion löscht den vorherigen Cache.

Warum zeigt App Service zuvor bereitgestellte Dateien nach einem Neustart an, wenn ein lokaler Cache aktiviert ist?

Wenn zuvor bereitgestellte Dateien nach einem Neustart erneut angezeigt werden, überprüfen Sie, ob die App-Einstellung WEBSITE_DISABLE_SCM_SEPARATION=truevorhanden ist. Wenn Sie diese Einstellung hinzufügen, werden Bereitstellungen über Kudu in den lokalen virtuellen Computer anstelle des beständigen Speichers geschrieben. Um diese Situation zu vermeiden, befolgen Sie die oben erwähnten bewährten Methoden , und führen Sie Bereitstellungen für einen Stagingplatz aus, für den kein lokaler Cache aktiviert ist.

Verwandte Inhalte