Überblick über Web Application Acceleration

Listet Konzepte auf, die mit dem Web Application Acceleration-Service verknüpft sind, und beschreibt sie.

Beschleunigung

Beschleunigungen binden Webanwendungsbeschleunigungs-Policys an Load Balancer. Wenn Sie eine Beschleunigung an eine Webanwendungsbeschleunigungs-Policy anhängen, weisen Sie dieser Policy einen Load Balancer zu, und die Bestimmungen der Policy werden auf die Vorgänge des Load Balancers angewendet

Caching

Ermöglicht das Caching am Load Balancer, um die Latenz zu reduzieren und eine erhöhte Last auf den Backend-Servern zu vermeiden.

Cache-Löschvorgang

Die Caches eines oder mehrerer Load Balancer mit der Beschleunigung werden aus Daten gelöscht.

Hinweis

Das Löschen von Caches kann nicht rückgängig gemacht werden.

Komprimierung

Bei der Auswahl von Caching ist die Komprimierung eine Option. Komprimierungen komprimieren Backend-Serverantworten, bevor sie an den Webanwendungsbenutzer zurückgegeben werden, um die erforderliche Bandbreite zu reduzieren. Diese Komprimierung beschleunigt die Übertragung der Serverantworten über das Netzwerk. Derzeit wird nur der GZIP-Komprimierungsalgorithmus unterstützt.

Load Balancer

Load Balancer bestimmen das Traffic-Routing. Sie können die Performance von Load Balancern verbessern, indem Sie ihnen Beschleunigungs-Policys für Webanwendungen zuweisen.

Webanwendungsbeschleunigungs-Policy

Webanwendungsbeschleunigungs-Policys legen die Parameter für die Anwendung von Beschleunigungen auf Webdatenverkehr mit Caching und Komprimierung fest.

Web Application Acceleration ist ein Service, mit dem der Traffic auf den Load Balancern beschleunigt werden kann, indem eine Kombination aus Caching und Komprimierung angewendet wird.

Caching und Komprimierung erfolgen für jede 200-Antwort auf eine GET- oder HEAD-Anforderung, die kleiner als die maximale Cachegröße ist. Caching und Komprimierung treten nicht auf, wenn die folgenden Header vorhanden sind:

• Cache-Control: no-cache

• Cache-Control: private

Durch Caching und Komprimierung kann der Traffic an den Load Balancern erheblich beschleunigt werden. Für die Verwendung dieser Features gelten jedoch die folgenden Einschränkungen:

• Caching

  • Nur HEAD- und GET-Anforderungen werden im Cache gespeichert.

  • Nur Antworten, die den HTTP-Statuscode 200 zurückgeben, werden im Cache gespeichert.

  • Zwischengespeicherte Inhalte bleiben mit Inhalten auf den gesicherten Servern möglicherweise erst aktuell, wenn der Cache abläuft oder gelöscht wird.

  • Inhalt wird zwischengespeichert, bis er abläuft oder gelöscht wird, auch wenn die Datei vom Backend-Server entfernt wird.

  • Backend-Server können einen drastischen Trafficanstieg erzielen, wenn eines der folgenden Ereignisse eintritt:

    • Mehrere Cache-Elemente laufen gleichzeitig ab.

    • Der Cache wird gelöscht.

    • Der Web Application Acceleration-Service ist deaktiviert.

  • Die maximale Cachegröße beträgt 100 MB. Nachdem diese maximale Größe erreicht wurde, entfernt der Web Application Acceleration-Service die Ressourcen, auf die am wenigsten zugegriffen wurde, bis die maximale Größe nicht mehr überschritten wird.

    Sie können keine Dateien mit mehr als 100 MB cachen.

    Hinweis
    
    

    Sie können anfordern, die Cachegröße des Web Application Acceleration Service zu erhöhen. Weitere Informationen finden Sie unter Erhöhung des Servicelimits beantragen.

  • Antworten, die den Set-Cookie-Header zurückgeben, werden nicht im Cache gespeichert.

  • Oracle empfiehlt, keine dynamischen Seiten im Cache zu speichern, da sie Informationen austauschen können.

• Komprimierung:

  • Wenn Sie die Komprimierung deaktivieren, als sie zuvor aktiviert war, kann es zu einer erhöhten Anforderungslatenz bei zunehmenden Datendownloads für Benutzer Ihrer Webanwendungen kommen.

Standardmäßig wird die Antwort 10 Minuten lang gecacht. Sie können die Cachezeit konfigurieren, indem Sie einen der Antwortheader für die Cachezeit in der vom Backend-Server zurückgegebenen Antwort festlegen.

Die folgenden Cachezeitheader werden unterstützt:

• Cache-Control: Wählen Sie die Anweisungen max-age oder s-maxage aus, um die Cachezeit festzulegen. Beide Anweisungen geben an, wie lange die Antwort in Sekunden im Cache gespeichert wird. Beispiel: Cache-Control: max-age=300 cacht die Antwort für 300 Sekunden. Wenn sowohl die Anweisungen max-age als auch s-maxage vorhanden sind, hat s-maxage Vorrang.

• Abgelaufen: Geben Sie das Datum/die Uhrzeit an, nach dem/der die Antwort als abgelaufen betrachtet wird. Verwenden Sie nur das HTTP-Datumsformat (RFC2616), um das Datum/die Uhrzeit anzugeben. Beispiel: Expires: Mon, 20 Feb 2023 12:45:26 GMT cacht die Antwort bis zu diesem Datum.

• X-Accel-Expires: Geben Sie die Caching-Zeit einer Antwort in Sekunden an. Der Nullwert (0) deaktiviert das Caching für eine Antwort. Wenn der Wert mit dem Präfix @ beginnt, wird eine absolute Zeit in Sekunden seit Epoch festgelegt. Die Antwortzeit wird bis zu diesem Zeitpunkt im Cache gespeichert. Beispiel: X-Accel-Expires: 300 cacht die Antwort für 300 Sekunden. X-Accel-Expires: @1676901818 cacht die Antwort bis Montag, 20. Februar 2023 14:03:38 GMT.

Konfigurieren Sie die Cachezeit basierend auf der erwarteten Lebensdauer einer gecachten Antwort. Wenn der Inhalt statisch (unveränderbar) ist, konfigurieren Sie den Cache für einen längeren Zeitraum. Wenn sich der Inhalt häufig ändert, konfigurieren Sie den Cache für einen kürzeren Zeitraum. Um die besten Ergebnisse zu erzielen, cachen Sie die Ablaufzeit, damit sie mit der Aktualisierungszeit des Inhalts übereinstimmt.