ICM Server-Cache
Der ICM Server-Cache oder Internet Server-Cache speichert HTTP(S)-Objekte, bevor sie zum Client geschickt werden. Beim nächsten Mal, wenn dieses Objekt durch einen Request angefordert wird, kann der Inhalt direkt aus dem Cache dem Client geschickt werden.
Wenn Response-Seiten wieder verwendet werden sollen (etwa die Einstiegsseite eines Internet-Shops), kann der HTTP-Request-Handler den ICM Server-Cache benutzen. Dieser speichert die Seiten, bevor sie zum Client gesendet werden. Beim nächsten Aufruf der entsprechenden URL wird dann - sofern die Verfallszeit nicht abgelaufen ist - die Seite direkt vom ICM an den Client zurückgeschickt; es muss in diesem Fall nicht in den Workprozess verzweigt werden.
Die Objekte des MIME-Repositorys werden standardmäßig im Cache gespeichert. Die Aktivierung des ICM Server-Cache erfolgt durch Methodenaufrufe wie später beschrieben.
Der Einsatz des ICM Server-Cache bringt einen erheblichen Performancegewinn.
Benchmark Tests für Cache-Treffer im Hauptspeicher haben latente Antwortzeiten von unter einer Millisekunde pro Request und einen Gesamtdurchlauf von über 3000 Requests pro Sekunde auf einer 4-CPU Hardware ergeben.
Diesen Ergebnissen liegt eine stark parallele und multithreaded Architektur zugrunde, die gleichzeitige Lese- und Schreibzugriffe mit Versionierung unterstützt. Außerdem wird hier für den schnellen Zugriff auf das Cache-Verzeichnis ein patentierter Indizierungsalgorithmus verwendet, der z.B. für lange Web-URLs als Cache-Keys besonders geeignet ist.
Der ICM Server-Cache ist Teil des Internet Communication Manager (ICM).
Folgende Grafik zeigt die Architektur des ICM Server-Cache.
Der ICM Server-Cache beinhaltet folgendes:
-
Zweistufige Cache-Hierarchie: Memory Cache und Disk Cache
-
Dynamische Caching-Technologie
-
Aktives Caching
-
UFO-Caching (UnFound Objects)
-
Browserabhängiges Caching
Zweistufige Cache-Hierarchie
Der ICM Server-Cache besteht aus einer zweistufigen Hierarchie: Eine sehr schnelle Hauptspeicher-Ablage ( MemoryCache) setzt auf einem Laufwerk-basierten Disk Cach e auf. Dies hat den Vorteil, dass sowohl die Schnelligkeit des Hauptspeicherzugangs als auch die große Ablagekapazität der Festplattenablage genutzt werden kann.
Dynamische Caching-Technologie
Konventionelle Web-Caching Szenarios basieren auf HTTP-Proxies und unterstützen in der Regel lediglich das Caching von statischen Inhalten, z.B. von GIF-Bildern. Der Internet Server Cache dagegen kann zusätzlich zu statischem Content auch dynamischen Web-Content speichern, z.B. JSP und BSPs. Dies ist bei der immer stärker zunehmenden Dynamisierung von Web-Anwendungen von zentraler Bedeutung.
Aktives Caching
Ein weiterer Unterschied zwischen existierenden Standard-Web-Caching Lösungen und dem Internet Server Cache besteht in der von der Anwendung gelenkten Cache-Kontroll-Technologie, die in das Internet Communication Framework integriert ist.
Aktives Caching bedeutet, dass die Anwendung volle Kontrolle über die Aktualität der im Cache liegenden Objekte besitzt. Dies geschieht durch die Verwendung von asynchroner Content-Invalidierung, die von anwendungsabhängigen Events ausgelöst wird. Auch dies läuft somit konträr zum Standard-HTTP-Caching ab, bei dem die Anwendung nur eine beschränkte Kontrolle über die Aktualität der im Cache liegenden Objekte hat. Üblicherweise werden bei der Standard-HTTP-Caching-Technologie Verfallszeit-Heuristiken verwendet.
UFO-Caching (Unfound Objects)
Der Internet Server Cache unterstützt das Caching von ungültigen Requests. Das sind Requests, die zu Fehlersituationen auf dem Applikationsserver oder dem Datenbank-Backend führen würden, z.B. "not found"- Fehler. Dadurch wird das Backend von Überlastsituationen abgeschirmt, bei denen das System von ungültigen oder bösartigen Web-Requests überflutet wird.
Beachten Sie, dass diese Funktion nur als grober Schutz dient und das System nicht gegen ausgefeiltere Angriffe schützen kann.
GZIP-Komprimierung
Wenn der Client GZIP-Komprimierung unterstützt (Headerfeld accept-encoding), und der Server die Antwort mit GZIP komprimiert hat (Headerfeld: content-encoding), so wird die Antwort komprimiert im Cache eingelagert. Im Cache-Key (s.u.) ist dann GZ=1 gesetzt.
Beachten Sie, dass die GZIP-Komprimierung nur für HTTP1.1 unterstützt ist. Wird als Protokoll HTTP1.0 verwendet, wird die Response nicht komprimiert.
Browserabhängiges Caching
Es ist möglich, dass eine HTML-Seite in verschiedenen Browsern unterschiedlich aussieht, da der HTML-Code nicht immer gleich interpretiert wird.
Darum kann der ICM Server-Cache die Seiten abhängig vom Browser-Typ einlagern. Wird dann dieselbe Seite von einem anderen Browser angefordert, kann die Anfrage nicht aus dem Cache befriedigt werden. Um der Laufzeitumgebung mitzuteilen, ob der Content browserabhängig ist, können Sie bei den Eigenschaften der Seite das entsprechende Kennzeichen setzen. Standardmäßig ist das Kennzeichen nicht gesetzt.
Wie arbeitet der ICM Server-Cache?
Wie der Cache nun im Einzelnen vorgeht, um Objekte zu identifizieren, einzulagern und zu invalidieren, ist in den folgenden Abschnitten beschrieben.
Profilparameter zur Konfiguration des ICM Server Cache
Folgende Parameter stehen zur Parametrisierung des ICM Server-Cache zur Verfügung:
icm/HTTP/server_cache_<xx>/size_MB
icm/HTTP/server_cache_<xx>/memory_size_MB
icm/HTTP/server_cache_<x>/max_entries
icm/HTTP/server_cache_<xx>/clear
icm/HTTP/server_cache_<xx>/expiration
icm/HTTP/server_cache_<xx>/max_name_len
Monitoring
Sie können den ICM Server-Cache mit der Webadministrationsoberfläche oder dem ICM Monitor (AS ABAP) überwachen