Freigeben über

Übersicht über den lokalen Cache von Azure App Service

  • Artikel

Hinweis

Lokaler Cache wird in Funktions-Apps oder containerisierten App Service-Apps nicht unterstützt, z. B. in Windows-Containern oder in App Service für Linux. Eine Version des lokalen Caches, die für diese APP-Typen verfügbar ist, ist App-Cache.

Azure App Service-Inhalt wird in Azure Storage gespeichert und dauerhaft als Inhaltsfreigabe bereitgestellt. Dieses Design ist auf den Einsatz mit einer Vielzahl von Apps ausgelegt und weist die folgenden Merkmale auf:

  • Der Inhalt wird über mehrere VM-Instanzen der App hinweg freigegeben.
  • Der Inhalt wird dauerhaft bereitgestellt und kann durch ausgeführte Apps geändert werden.
  • Protokolldateien und Diagnosedatendateien stehen unterhalb desselben freigegebenen Inhaltsordners zur Verfügung.
  • Beim Veröffentlichen neuer Inhalte wird der Inhaltsordner direkt aktualisiert. Der Inhalt kann umgehend über die SCM-Website und die ausgeführte App angezeigt werden. (Einige Technologien wie z. B. ASP.NET initiieren bei einigen Dateiänderungen üblicherweise einen App-Neustart, um die aktuellen Inhalte abzurufen.)

Während viele Apps einzelne oder alle dieser Features nutzen, benötigen einige Apps lediglich einen hochleistungsfähigen schreibgeschützten Inhaltsspeicher, aus dem sie mit Hochverfügbarkeit ausgeführt werden können. Diese Apps können von einer VM-Instanz eines bestimmten lokalen Caches profitieren.

Der lokale Cache von 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 lokalem Cache ausgeführt werden, bieten die folgenden Vorteile:

  • Sie werden nicht durch Latenzen beeinträchtigt, die beim Zugriff auf Inhalt in Azure Storage auftreten.
  • Sie sind nicht von Verbindungsproblemen mit dem Speicher betroffen, da die schreibgeschützte Kopie auf dem Worker zwischengespeichert ist.
  • Es sind weniger App-Neustarts aufgrund von Änderungen an der Speicherfreigabe erforderlich.

Hinweis

Wenn Sie Java (Java SE, Tomcat oder JBoss EAP) verwenden, werden die Java-Artefakte – JAR-, WAR- und EAR-Dateien – standardmäßig lokal auf den Worker kopiert. Wenn Ihre Java-Anwendung auch von schreibgeschütztem Zugriff auf andere Dateien abhängig ist, legen Sie für diese Dateien JAVA_COPY_ALL auf true fest, damit sie auch kopiert werden. Wenn der lokale Cache aktiviert ist, hat er Vorrang vor dieser Java-spezifischen Verbesserung.

Auswirkung des lokalen Caches auf das Verhalten von App Service

  • D:\home verweist auf den lokalen Cache, der beim Starten der App auf der VM-Instanz erstellt wird. D:\local verweist weiterhin auf den temporären VM-spezifischen Speicher.
  • Der lokale Cache enthält eine einmalige Kopie der Ordner /site und /siteextensions des freigegebenen Inhaltsspeichers unter D:\home\site bzw. D:\home\siteextensions. Die Dateien werden beim Starten der App in den lokalen Cache kopiert. Die Größe der beiden Ordner ist pro App standardmäßig auf 1 GB beschränkt, kann aber auf bis zu 2 GB erhöht werden. Beachten Sie, dass mit zunehmender Größe das Laden des Caches länger dauert. Wenn Sie die Größe des lokalen Caches auf 2 GB heraufgesetzt haben und die kopierten Dateien das Maximum von 2 GB überschreiten, ignoriert App Service den lokalen Cache im Hintergrund und führt Lesevorgänge in der Remotedateifreigabe durch.

Wichtig

Wenn die kopierten Dateien den definierten Grenzwert für die Größe des lokalen Caches überschreiten oder wenn kein Grenzwert definiert ist, können Bereitstellungs- und Swappingvorgänge mit einem Fehler fehlschlagen. Weitere Informationen finden Sie in den FAQ.

  • Der lokale Cache bietet Lese- und Schreibzugriff. Änderungen werden jedoch verworfen, wenn die App zwischen virtuellen Computern verschoben oder neu gestartet wird. Verwenden Sie den lokalen Cache nicht für Apps, die unternehmenskritische Daten im Inhaltsspeicher speichern.
  • D:\home\LogFiles und D:\home\Data enthalten Protokolldateien und App-Daten. Die zwei Unterordner werden lokal auf der VM-Instanz gespeichert und regelmäßig in den freigegebenen Inhaltsspeicher kopiert. Apps können Protokolldateien und Daten speichern, indem sie diese in die jeweiligen Ordner schreiben. Das Kopieren in den freigegebenen Inhaltsspeicher erfolgt jedoch nach dem Prinzip der besten Leistung, daher können Protokolldateien und Daten aufgrund eines plötzlichen Absturzes einer VM-Instanz verloren gehen.
  • Das Protokollstreaming wird durch den bestmöglichen Kopiervorgang beeinträchtigt. Bei den gestreamten Protokollen kann es zu einer Verzögerung von bis zu einer Minute kommen.
  • Im freigegebenen Inhaltsspeicher ergibt sich für Apps, die den lokalen Cache verwenden, eine Änderung in der Ordnerstruktur der Ordner LogFiles und Data. In diesen Ordnern sind jetzt Unterordner vorhanden, die das Benennungsmuster „eindeutiger Bezeichner + Zeitstempel“ aufweisen. Jeder dieser Unterordner entspricht einer VM-Instanz, auf der die App ausgeführt wird oder wurde.
  • Andere Ordner im Verzeichnis D:\home verbleiben im lokalen Cache und werden nicht in den freigegebenen Inhaltsspeicher kopiert.
  • Bei der App-Bereitstellung über eine unterstützte Methode erfolgt die Veröffentlichung direkt im permanenten freigegebenen Inhaltsspeicher. Zum Aktualisieren der Ordner D:\home\site und D:\home\siteextensions im lokalen Cache muss die App neu gestartet werden. Informationen zu einem nahtlosen Lebenszyklus finden Sie weiter unten in diesem Artikel.
  • Die standardmäßige Inhaltsansicht der SCM-Site ist weiterhin die des freigegebenen Inhaltsspeichers.

Aktivieren des lokalen Caches in App Service

Hinweis

Der lokale Cache wird in den Tarifen F1 oder D1 nicht unterstützt.

Der lokale Cache wird mithilfe einer Kombination aus reservierten App-Einstellungen konfiguriert. Diese App-Einstellungen können über die folgenden Methoden konfiguriert werden:

Konfigurieren des lokalen Caches über das Azure-Portal

Der lokale Cache wird für jede Web-App über die folgende App-Einstellung aktiviert: WEBSITE_LOCAL_CACHE_OPTION = Always

Azure portal app settings: Local Cache

Konfigurieren des lokalen Caches mit 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 im lokalen Cache

Standardmäßig ist der lokale Cache 1 GB groß. Dies schließt die Ordner „/site“ und „/siteextensions“ ein, die aus dem Inhaltspeicher kopiert werden, sowie alle lokal erstellten Protokolle und Datenordner. Um dieses Limit zu erhöhen, verwenden Sie die folgende App-Einstellung: WEBSITE_LOCAL_CACHE_SIZEINMB. Die Größe kann auf bis zu 2 GB (2.000 MB) pro App erhöht werden. Beachten Sie, dass mit zunehmender Größe das Laden des lokalen Caches länger dauert.

Bewährte Methoden für die Verwendung des lokalen Caches von App Service

Es wird empfohlen, den lokalen Cache gemeinsam mit dem Feature Stagingumgebungen zu verwenden.

  • Fügen Sie die persistente App-Einstellung WEBSITE_LOCAL_CACHE_OPTION mit dem Wert Always zu Ihrem Produktionsslot hinzu. Wenn Sie WEBSITE_LOCAL_CACHE_SIZEINMBverwenden, fügen Sie diese Einstellung ebenfalls als persistente Einstellung zu Ihrem Produktionsslot hinzu.
  • Erstellen Sie einen Stagingslot, und führen Sie eine Veröffentlichung in Ihrem Stagingslot durch. Für den Stagingslot wird üblicherweise nicht die Verwendung des lokalen Caches festgelegt. So wird ein nahtloser Lebenszyklus für das Erstellen/Bereitstellen/Testen für das Staging ermöglicht, während die Vorteile des lokalen Caches für den Produktionsslot genutzt werden.
  • Testen Sie Ihre Site mit dem Stagingslot.
  • Wenn Sie bereit dazu sind, wechseln Sie über einen swap-Vorgang zwischen Ihrem Staging- und Ihrem Produktionsslot.
  • Persistente Einstellungen umfassen einen Namen und gelten dauerhaft für einen Slot. Wenn also der Stagingslot auf den Produktionsslot umgeschaltet wird, erbt dieser die App-Einstellungen für den lokalen Cache. Der neue Produktionsslot wird nach ein paar Minuten mit dem lokalen Cache ausgeführt und im Rahmen der Slotaufwärmung nach dem Wechsel aufgewärmt. Wenn der Slotwechsel abgeschlossen ist, wird Ihr Produktionsslot mit dem lokalen Cache ausgeführt.

Häufig gestellte Fragen (FAQ)

Was geschieht, wenn die Größenbeschränkung für den lokalen Cache überschritten wird?

Wenn die kopierten Dateien den Grenzwert für die Größe des lokalen Caches überschreiten, liest die Anwendung von der Remotefreigabe aus. Bereitstellungs- und Swapvorgänge können jedoch mit einem Fehler scheitern. In der folgenden Tabelle finden Sie Größenbeschränkungen und -ergebnisse.

 Größe des lokalen Caches Coped-Dateien Ergebnis
≤ 2 GB Größe des lokalen Caches Liest aus dem lokalen Cache.
≤ 2 GB > Größe des lokalen Caches Liest aus der Remotefreigabe.
Hinweis: Bereitstellungs- und Swapvorgänge können mit einem Fehler scheitern.

Ist der lokale Cache für meine App geeignet?

Wenn Ihre App einen zuverlässigen Hochleistungs-Inhaltsspeicher benötigt, den Inhaltsspeicher nicht zum Schreiben von unternehmenskritischen Daten zur Laufzeit nutzt und eine Gesamtgröße von maximal 2 GB erforderlich ist, dann lautet die Antwort: Ja, Ihre Anwendung ist für den lokalen Cache geeignet! Um die Gesamtgröße der Ordner „/site“ und „/siteextensions“ zu ermitteln, können Sie die Siteerweiterung „Azure Web Apps Disk Usage“ verwenden.

Woher weiß ich, dass meine Site auf die Verwendung des lokalen Caches umgeschaltet hat?

Wenn Sie das Feature für den lokalen Cache mit Stagingumgebungen verwenden, findet der Wechsel erst dann statt, wenn der lokale Cache aktiviert wurde. Um zu prüfen, ob Ihre Site mit dem lokalen Cache ausgeführt wird, können Sie die Workerprozess-Umgebungsvariable WEBSITE_LOCALCACHE_READYüberprüfen. Befolgen Sie die auf der Seite für die Workerprozess-Umgebungsvariable bereitgestellten Anweisungen, um auf mehreren Instanzen auf die Workerprozess-Umgebungsvariable zuzugreifen.

Ich habe soeben neue Änderungen veröffentlicht, aber in meiner App scheinen diese nicht verfügbar zu sein. Warum?

Wenn Ihre App den lokalen Cache verwendet, müssen Sie Ihre Site neu starten, um die neuesten Änderungen abzurufen. Sie möchten Änderungen nicht für eine Produktionssite veröffentlichen? Relevante Informationen finden Sie bei den Slotoptionen im oben stehenden Abschnitt zu den bewährten Methoden.

Hinweis

Die Bereitstellungsoption aus Paket ausführen ist mit dem lokalen Cache nicht kompatibel.

Wo sind meine Protokolle?

Bei Verwendung des lokalen Caches sehen Ihre Protokolle und Datenordner etwas anders aus. Die Struktur Ihrer Unterordner bleibt jedoch erhalten, mit der Ausnahme, dass sie unterhalb eines Unterordners mit folgendem Format geschachtelt sind: „eindeutiger VM-Bezeichner“ + Zeitstempel

Ich habe den lokalen Cache aktiviert, aber meine App wird weiterhin neu gestartet. Warum? Ich dachte, durch den lokalen Cache werden App-Neustarts verringert.

Der lokale Cache trägt dazu bei, speicherbezogene Neustarts von Apps zu vermeiden. Ihre App kann jedoch aufgrund von geplanten Upgrades der VM-Infrastruktur weiterhin neu gestartet werden. Die App sollte bei aktiviertem lokalen Cache insgesamt jedoch seltener neu gestartet werden.

Gibt es Verzeichnisse, die für den lokalen Cache nicht auf das schnellere lokale Laufwerk kopiert werden?

Bei dem Schritt, in dem der Speicherinhalt kopiert wird, werden alle Ordner mit dem Namen „repository“ ausgeschlossen. Dies hilft bei Szenarien, in denen eine Website ein Quellcodeverwaltungs-Repository enthält, das für den täglichen Betrieb der App möglicherweise nicht benötigt wird.

Wie werden die Protokolle im lokalen Cache nach einem Standortverwaltungsvorgang geleert?

Zum Leeren der Protokolle im lokalen Cache beenden Sie die App, und starten Sie sie erneut. Durch diese Aktion wird der alte Cache gelöscht.

Warum wird App Service bei aktiviertem lokalem Cache nach einem Neustart mit bereits bereitgestellten Dateien angezeigt?

Wenn der App-Dienst bei einem Neustart bereits bereitgestellte Dateien anzeigt, überprüfen Sie, ob die App-Einstellung „WEBSITE_DISABLE_SCM_SEPARATION=true“ aktiviert ist. Nach dem Hinzufügen dieser Einstellung schreiben alle KUDU-basierten Bereitstellungen auf den lokalen virtuellen Computer anstatt in den persistenten Speicher. Es empfiehlt sich, die weiter oben in diesem Artikel erwähnten bewährten Methoden zu verwenden. Diese besagen, dass die Bereitstellungen immer im Stagingslot erfolgen sollten, für den der lokale Cache nicht aktiviert ist.

Weitere Ressourcen

Referenz zu Umgebungsvariablen und App-Einstellungen