Verschiedene Caching-Techniken für Web Map Services

Transkript

1 191 Verschiedene Caching-Techniken für Web Map Services Alexander LOECHEL und Stephan SCHMID Dieser Beitrag wurde nach Begutachtung durch das Programmkomitee als reviewed paper angenommen. Zusammenfassung Die Nachfrage nach digitalen Karten im Internet ist in den letzten Jahren stetig angestiegen. Digitale Karten werden nicht nur von großen kommerziellen Kartenanbietern bereitgestellt, sondern zunehmend auch von Bundes- und Landesbehörden, sowie privaten Webseiten. Dadurch rücken die Performanz und der fehlerfreie Betrieb der Geo Web Services weiter in den Fokus. Im Folgenden werden die Grundlagen des Cachings, basierend auf Geo-Tile- Caching, Reverse-Proxy-Caching und Web Application Acceleration für standardisierte OGC Web Map Services vorgestellt. 1 Einleitung Die Nutzung von digitalen Karten auf Webseiten ist in den letzten Jahren stetig angestiegen. Derzeit dominieren noch kommerzielle Kartenanbieter wie Google Maps, Bing Maps und andere Anbieter den Markt. Die Nutzung dieser kommerziellen Anbieter hat den Vorteil, dass der Nutzer seine digitalen Karten von einem hoch performanten Server Cluster erhält. Dieser Server Cluster nutzt verschiedenen Möglichkeiten um die Generierung der Karten für den Nutzer zu beschleunigen. Dadurch wird die Internetverbindung des Nutzers zum limitierenden Faktor bei der Übertragung und Anzeige der Karten [1]. Sobald in einem GIS-Projekt eigene Web Map Service (WMS) Server (z. B. GeoServer) verwendet werden, dauert das Laden und Rendern der Karten, im Vergleich zu den kommerziellen Karten Anbietern häufig deutlich länger. Dies resultiert meist aus einem Mangel an leistungsstarker Hardware oder unzureichendem Wissen über Caching-Techniken, bzw. wie diese optimal anzuwenden sind. Dies führt dazu, dass diese Dienste aufgrund ihrer langen Ladezeiten häufig gemieden werden, da Nutzer meist nicht länger als drei Sekunden warten möchten, bis eine Webseite komplett geladen ist [2]. Am 15 Mai 2007 trat die INSPIRE (Infrastructure for Spatial Information in the European Community)-Richtlinie in Kraft, die vorschreibt, dass die Geodaten-Infrastrukturen der Mitgliedsstaaten untereinander kompatibel sein müssen um in länderübergreifenden Szenarios verwendet werden zu können [3]. Um dies zu gewährleisten wurde eine Reihe von Spezifikationen und Guidelines definiert. Ein wichtiges Dokument ist die INSPIRE Network Services Performance Guideline, die beschreibt wie schnell eine Anfrage von einem GIS Server beantwortet werden soll [4]. Strobl, J., Blaschke, T. & Griesebner, G. (Hrsg.) (2012): Angewandte Geoinformatik Herbert Wichmann Verlag, VDE VERLAG GMBH, Berlin/Offenbach. ISBN

2 192 A. Loechel und S. Schmid Im Folgenden werden verschiedene Möglichkeiten einen WMS zu cachen betrachtet. Dabei werden Ansätze aufgezeigt um eine hoch performante low cost WMS-Umgebung für GIS Projekte zu schaffen. Es werden Benchmark Tests mit unterschiedlichen Caching-Anwendungen durchgeführt. Die Ergebnisse dieser Tests werden analysiert und in Bezug zur INSPIRE-Richtlinie gesetzt um zu zeigen wie Caching-Techniken helfen WMS-Antwortzeiten zu reduzieren um die Direktive zu erfüllen. INSPIRE-Richtlinie Die INSPIRE-Richtlinie definiert Performanz eines Geo Web Service als die Zeit, wie schnell eine WMS-GetMap-Anfrage an den WMS-Server erfüllt werden kann. Die umfasst mehrere Unterpunkte [4]: Response time ist die Zeit, die zwischen Absenden des WMS GetMap Requests und dem Erhalt des Karten Bildes vergeht. Transaction time ist die Zeit die benötigt wird um eine komplette Transaktion durchzuführen. Die Zeit variiert je nach Definition einer Transaktion. Latency ist der Round-Trip Delay (RTD), die Zeit für die reine Datenübertragung über die Netzverbindung Execution time ist die Zeit, die der WMS-Server benötigt für die Generierung der Karte, bzw. für die interne Abarbeitung des WMS-Request. Weiterhin beschreibt die INSPIRE-Richtlinie ein Service Level Agreement für die Nutzung von standardisierten WMS-Diensten in einer INSPIRE-Umgebung: For a 470 KB image the response time for sending the initial response to a GetMap request to a view shall be a maximum of 5 seconds in a normal situation. A normal situation represents a period out of peak load, which is set at 90 % of the time [6]. 2 Caching-Theorie 2.1 Grundlegende Caching-Techniken Dieser Abschnitt erläutert die technischen Hintergründe des Caching/der Zwischenspeicherung in einem HTTP-Umfeld. Zu Beginn des World Wide Web (WWW), waren rein statische Inhalte auf Webseiten üblich. Heute hat die Nachfrage nach Echtzeit-Informationen den Bedarf an dynamisch generierten Inhalten stark steigen lassen. Da aber die just-in-time Generierung von dynamischen Inhalten normalerweise langsam ist, wurde Caching eine übliche Technik um Inhalte performant bereit zu stellen [7]. Die Präambel des HTTP-Standards beschreiben bereits einige der Hauptattribute des Protokolls: generic/generisch nicht an einen bestimmten Content Type (z. B. HTML, Text, Bilder) oder Use-Case gebunden. stateless/zustandslos ein identischer GET Aufruf sollte immer die gleiche Antwort zur Folge haben.

3 Verschiedene Caching-Techniken für Web Map Services 193 Das HTTP-Protokoll definiert 10 Abfragearten (z. B. GET, POST, PUT, TRACE). Statistisch gesehen spielen nur zwei Abfragearten eine Rolle: GET und POST, Beiden machen aber in der Regel mehr als 95 % der HTTP-Anfragen an Web Services aus. HTTP-GET-Requests fordern ein HTTP-Dokument von einem Server an, definiert durch einen Uniform Ressource Identifier (URI). HTTP-POST-Requests sind in der Regel clientseitige Antworten, welche für die Übertragung größere Datenmengen oder Formulardaten verwendet werden. Das HTTP-Protokoll beschreibt somit die Kommunikation zwischen Web-Clients (z. B. Browsers der speziellen Anwendungen) und einem Server. Es definiert ähnlich einem Vertrag dabei, wie die angeforderten Ressourcen übermittelt werden sollen, in den HTTP- Headern. Der HTTP-Standard definiert eine Anzahl an Standard Headern, welche beispielsweise das Erzeugungsdatum, Client und Server Daten, den zu übertragenden Content Type als auch Caching-Direktiven umfassen. HTTP selber ist als zustandslos definiert, dies bedeutet, dass identische Aufrufe in identische Antworten münden sollen. Deswegen kann prinzipiell jede Antwort auf eine Anfrage gecacht werden. Das Protokoll definiert aber eine große Ausnahme, die Übertragung von Daten auf den beiden Anfragearten Get und Post, weswegen Shared-Caches normalerweise POST-Anfragen und jegliche GET-Anfragen die ein? (query-call) in der URI enthalten ignorieren. Diese werden als Sonderfälle behandelt und nicht beachtet. Ein Browser erwarten nicht, dass diese gecacht werden können oder dass Cache-Header für eine solche Anfrage gesetzt sind. Das OGC (Open Geospatial Consortium) spezifiziert ihre Web Services auf Basis dieser POST und GET-Queries, sodass eine OGC Web Service (OWS) Anfrage normalerweise nicht gecacht wird. Der HTTP-Standard definiert verschiedene Techniken um Shared-Caches und Browsern mitzuteilen, das Inhalte (statische und dynamische) gecacht werden sollen, die HTTP-Cache-Header. 2.2 HTTP-Cache-Header Das HTTP-Protokoll Version 1.1 definiert einige HTTP-Header-Statements. Zum Caching von Web-Inhalten existieren sowohl Header Statements als Teil der Anfrage (HTTP request/client side values) als auch Statements die als Antwort (HTTP response/server side values) gesendet werden [8]. Im Folgenden werden verschiedene wichtige Cache-Header vorgestellt: Expires header: der Expires Header ist ein Header der nur in einer Antwort verwendet wird. Er enthält ein Datum nach dem RFC 1123 Standard, ab welchem der Cache Eintrag als nicht mehr aktuell akzeptiert werden soll. If-Modified-Since header: Der If-Modified-Since Header ist ein request-only Header, der Browser oder Shared-Cache nutzt diesen um ein Dokument nur dann abzufragen wenn es seit dem letzten Aufruf verändert wurde. Ein Antwort mit dem HTTP-Status- Code 304 Not Modified bedeutet, das keine Änderungen vorgenommen wurden. 2.3 Caching und die Veränderung der Daten das Purge Problem Caching basiert auf einem Vertrag zwischen dem Client und dem Server, formell in den Cache Headern vereinbart. Oft sind diese Header nicht richtig gesetzt oder können durch den GIS Server nicht gesetzt werden. In diesen Fällen können Backend Web-Server (z. B.

4 194 A. Loechel und S. Schmid Apache httpd Web Server) eingesetzt werden um die GIS Server Antwort um die Cache Header zu erweitern [8]. Die Nutzung eines Cache kann zu einem großen Problem führen, wenn eine Aktualisierung von Cache-Inhalten nach einer Modifikation auf Datenebene nicht durchgeführt wird. In einem Web-Kontext wird auch von dem Purge Problem gesprochen. Es können verschiedene Ebenen eines Cache vorhanden sein, dabei kann es sich um Shared Caches handeln, die als Proxy Server im Internet oder im administrierten Bereich der IT-Infrastruktur fungieren. Diese können verschiedene Caching-Informationen enthalten. Falls die Cache Header gesetzt sind, werden die Daten in der Regel nur aus dem Cache abgefragt. Somit ist nicht sichergestellt, dass der Cache Informationen über Änderungen der Daten mitbekommt, bis eine Anfrage den Cache zum Erneuern zwingt. Dieser Vorgang der Cacheerneuerung kann komplex werden, da der GIS Server nicht alle Shared Caches kennt, die sich außerhalb des administrierten Bereiches der IT-Infrastruktur befinden. Angenommen alle Shared Caches verhalten sich HTTP-Standard konform, was bedeutet das Purge Problem für den Nutzer? Ein Server kann veraltete Karten liefern, da der Expires-Header oder der Cache-Control: max-age=seconds erlaubt den aktuellen Cache Inhalt immer auszuliefern. Dies ist besonders in zwei Fällen kritisch. 1. Änderungen der Daten durch Nutzer: Änderungen der Daten über einen Browser z. B. durch die Nutzung eines WFS-T. 2. Sich schnell ändernde Daten: Öffentliche Karten mit aktuellen Informationen, z. B. Verkehrsinformationen oder Wetter Daten. 3 Caching-Software Ein WMS-Server kann in Kombination mit einem modernen Ajax Client (z. B. OpenLayers) eine umfassende Geo Web Applikation bilden, welche auf dem WMS-Tiles Service basiert. WMS-Tile-Services sind schon lange Bestandteil in der Wissenschaft [6]. Der Download dieser Tiles ist jedoch meist langsam. Für jedes einzelne Tile müssen die benötigten Daten aus (verschiedenen) Datenbanken an den GIS Server übertragen und die Karte generiert werden. Weiterhin müssen möglicherweise unterschiedliche Parameter zum Rendern der Karte (diese können gecacht vorliegen) erfragt, eine Koordinatentransformation durchgeführt sowie die digitale Karte aus allen Informationen erstellt werden. Dies kann ein langsamer Prozess sein und schnell zu langen Ladezeiten führen. In der Web-Technologie sind generische HTTP-Caching-Techniken weiter verbreitet. Die generischen Systeme können alle gültigen WMS-Anfragen cachen. Ein weiterer Vorteil liegt in der Geschwindigkeit im Falle eines Fehlers. Wenn ein GIS Server ein Tile generiert, wird Zeit benötigt dieses Tile zum Client zu transportieren. Dazu wird ein Thread des Servers geblockt, dieser ist damit an die Bandbreite gebunden. Kommt eine generische Caching-Software zum Einsatz ist diese in der Regel direkt an den GIS Server angebunden und kann damit dieses Problem verringern. Der folgende Abschnitt erläutert die verwendete Software für die Performanz-Tests. Dabei wird sowohl Tile-Caching-Software als auch generische HTTP-Caching-Software verwendet.

5 Verschiedene Caching-Techniken für Web Map Services Tile-Caching-Software Der einfachste Weg die Bereitstellungsgeschwindigkeit der WMS-Tiles zu erhöhen, ist die Nutzung eines Tile Cache. GeoWebCache (GWC) ist eine Open-Source-Tile-Caching Service-Middleware, die von OpenGeo entwickelt wird. GWC unterstützt verschiedene OGC Standards, unter anderem WMTS, WMS-C, KML. GWC ist in Java umgesetzt und wird unter der GNU General Public License (GPL) vertrieben. 3.2 Generic HTTP-Web-Caching-Services und WMS Aus einer analytischen Sicht, sind WMS GetMap Requests einfache HTTP-Anfragen. Um HTTP-Anfragen zu cachen existieren viele verschiedene Ansätze. Im Folgenden werden drei häufig genutzte Caching-Anwendungen vorgestellt, welche später für die Performanz- Tests verwendet werden. Squid ist ein weitverbreiteter Reverse Proxy Server, der auch als Caching-Anwendung dient. Squid wurde von Duane Wessels an der Universität of Colorado für das Harvest object cache Projekt entwickelt. Ein großes Projekt, das Squid verwendet, ist die Wikipedia. Dieses Beispiel zeigt wie skalierbar und performant ein Web-Projekt sein kann. Squid stellt einen de facto Standard für große Caching-Projekte dar. Squid ist für alle Betriebssysteme verfügbar und wird unter der GPL Lizenz vertrieben. Die Konfiguration ist jedoch sehr komplex. Varnish ist ein einfacher HTTP-Application-Accelerator. Er wurde für dynamische Webseiten entwickelt und verhält sich wie ein Reverse Proxy Server. Seine Konfiguration ist deutlich einfacher gestaltet als bei Squid, jedoch ist Varnish nur für Linux erhältlich. Varnish ist open-source und wird unter der BSD Lizenz vertrieben. Apache mod_cache ist eine Erweiterung zum Apache HTTP-Web-Server. Es beinhaltet einen HTTP-konformen Cache, der entweder lokale oder bereits gecachte Inhalte aufbereiten kann. Es existieren zwei Speichermöglichkeiten für die gecachten Inhalte, diese können zum einen auf der Festplatte oder zum anderen im Arbeitsspeicher gecacht werden. Apache mod_cache kann keine Inhalte mit Zugriffsschutz cachen. 4 Performance Measurement Software Um verlässliche Performanz Werte zu erhalten, müssen die Messungen wiederholbar und nachvollziehbar sein. Im Folgenden werden zwei Benchmark Tools vorgestellt, die oft zur Performanz Messung von Web Services verwendet werden. Apache Benchmark (ab) ist ein Kommandozeilen basiertes Benchmark Tool und Teil des Apache httpd Web Server Projektes. Derzeit ist es der de Facto Standard um HTTP- Benchmark-Tests an einem Web Server durchzuführen. Es ist ein einfaches Tool welches die HTTP-Header analysiert und Informationen über verschiedene Performanz Faktoren, z. B. Anfragen pro Sekunde, Mittlere Antwortzeit pro Anfrage, Durchsatz etc. sammelt. Apache Benchmark ist nur in der Lage den Test gleichzeitig auf eine URI zu stellen. Apache JMeter ist eine Benchmark Tool mit einer grafischen Benutzeroberfläche. Es ist Teil des Apache Jakarta Projektes. Apache JMeter ist Open Source und in Java umgesetzt,

6 196 A. Loechel und S. Schmid es kann durch seine API leicht erweitert werden. JMeter kann Tests auf statischen oder dynamischen Inhalten durchführen. Diese beiden Tools ermöglichen die Messungen der Antwortzeit einer HTTP-Anfrage. Dies ist die Zeit vom Start der Anfrage bis zum Erhalt der Antwort. Es wird nicht das Rendern einer Webseite oder das HTTP-Antwort-Dokument analysiert. Die WMS-Funktionalität auf HTML-Webseiten wird üblicherweise durch JavaScript Frameworks wie OpenLayers umgesetzt. Allerdings werden beim Laden des HTML Dokumentes nicht die eingebetteten Ressourcen angefragt und nachgeladen. So werden durch diese Tools kein Java Skript angefragt und damit auch kein WMS-Request durchgeführt. Für die Performanz-Tests müssen demzufolge Anfragen auf dem Dienst Level durchgeführt werden. 5 Testsetup Das folgende Kapitel beschreibt die Hard- und Software Spezifikationen des Test Systems, die Aufbereitung der Test Daten sowie die genaue Testdurchführung. 5.1 Hard- und Software Für die Benchmark Tests wurde ein Testbed genutzt, welches aus drei Schichten besteht: Layer 1: Die Basis des Testbeds bildet eine leistungsstarke Server Hardware. Layer 2: Im Rahmen von Virtualisierung werden verschiedene unabhängige Server bereitgestellt. Somit können die Hardwareressourcen optimal genutzt werden. Layer 3: Der Zugriff auf die Geo Web Services erfolgt von außerhalb des Virtualisierungsservers. Dazu stellt der Server eine Netzwerkbrücke zu den virtuellen Servern her. Das Testsystem für die Benchmark Tests wurde nach dem Prinzip einer Service-Orientieren Architektur aufgesetzt. Die Konfiguration der Caching-Software folgt der Dokumentation für HTTP Acceleration/Caching. Für die Tests wurde Open-Source Daten vom OpenStreetMap Projekt verwendet. 5.2 Test Durchführung Die Tests untersuchen verschiedene Caching-Ansätze um die Performanz eines OGC- WMS-Servers zu erhöhen. Dies umfasst Tile-Caching, Reverse-Proxy-Caching und Web- Application Acceleration Software. Es wird das Verhalten der Caching-Software in Bezug auf hohe Nutzerzahlen als auch steigende gleichzeitige Zugriffe untersucht. Hierbei wird die Anwendbarkeit der INSPIRE-Richtlinie untersucht. non-cached: Es ist wichtig zu sehen wie ein ungecachtes System auf die steigende Anzahl an gleichzeitigen Zugriffen reagiert. Daraus können eventuelle Performanz Verbesserungen der Caching-Anwendungen geschlossen werden. Static tile image: Um einen Vergleichswert zu erzeugen wurde eine statische Version der Test Karte in die Tests aufgenommen. Da der Apache httpd Web Server damit nur statische Inhalte ausliefert, ist diese Karte sehr performant und kann als Referenzwert für die anderen Caching-Software benutzt werden.

7 Verschiedene Caching-Techniken für Web Map Services 197 GeoWebCache: Repräsentiert eine Tile Caching-Software. GeoWebCache stellt Tiles mit einer Größe von Pixeln bereit. Die Tiles wurden geseeded nachdem der Web Map Service aufgesetzt war. Apache mod_cache: Repräsentiert eine traditionelle Konfiguration des Webservers als Cache Proxy Server. Varnish: Repräsentiert einen spezielle Caching-Server, welche nicht Clusterfähig ist. Squid: Repräsentiert eine Caching-Software für den Einsatz in großen Cache Clustern. Für die Apache Benchmark Tests wurden zwei Versionen von Squid installiert. Die weitverbreitete Version 2.7 und die neue Reimplementierung Version 3.0. Squid, beide verhalten sich wie ein Reverse Proxy Server. Es wurden verschiedenen Tests mit Apache Benchmark durchgeführt, allerdings kann nur eine Ressource (eine URI, also ein Karten-Tile/Bild) pro Testlauf angefragt werden. Es wurde eine Anzahl an Anfragen (1 bis Aufrufe) bei gleichzeitigem Zugriff von bis zu Request durchgeführt. Dazu wurden mehrere Testläufe durchgeführt die auf zwei Testansätzen basieren. 1. Der erste Testansatz wurde mit einer Kartengröße von Pixel, der typischen WMS Tile Größe durchgeführt 2. Der zweite Testansatz wurde mit einer Kartengröße von Pixel durchgeführt. Dies entspricht der Beispielgröße in der INSPIRE-Richtlinie Für realitätsnahe Tests wurden zusätzliche Tests mit Apache JMeter durchgeführt. Da Apache JMeter einer Browser ähnliches Verhalten simulieren kann, können normale Zugriffsszenarien untersucht werden. In einer normalen Situation greifen mehrere Nutzer gleichzeitig auf verschiedene Tiles zu. Für die Tests wurden 12 Tiles mit einer Kartengröße von Pixel angefragt. Weiterhin wurden nach Vorgabe der INSPIRE-Richtlinie eine Kartengröße von Pixel angefragt. Alle Karten wurden im Format PNG ausgegeben. Die Tests wurden mit allen vier Layern, welche durch einen GeoServer bereitgestellt werden durchgeführt. Dabei wurden die Nutzerzugriffe in Dezimalschritten von 1 bis 100 Nutzer erhöht. 6 Ergebnisse Im folgenden Abschnitt werden die Ergebnisse der WMS-Performanz und Caching-Tests dargestellt und analysiert. Die Einführung der Benchmark Tools in Abschnitt 4 beschreibt die Funktionalität und Grenzen der Software. Tabelle 1 zeigt die erreichte Performanz jedes Systems. Die Tests wurden mit Apache Benchmark durchgeführt und können folgendermaßen zusammengefasst werden: Caching-Systeme erhöhen die Möglichkeit die Anfragen pro Sekunde auf durchschnittlich 3700/1050 (Varnish) Anfragen pro Sekunde, im Vergleich zu dem ungecachten GeoServer, welcher 50/25 Anfragen pro Sekunde erreicht. Dies ist eine Erhöhung um den Faktor 40-70, was die benötigte Zeit pro Anfrage von ms/41000 ms auf durchschnittlich 300 ms/ 950 ms reduziert, was dem Faktor entspricht. Die Tests verlaufen in beiden Testansätzen sehr performant und erfüllen die INSPIRE- Richtlinie in 90 % aller Anfragen in unter 65 ms. Die kleinen Unterschiede der Systeme GeoWebCache, Apache mod_cache und Varnish sind erstaunlich, alle Systeme liegen dicht

8 198 A. Loechel und S. Schmid zusammen. Der große Unterschied in der Performanz der Squid Versionen ist unerwartet kann aber auf die sehr komplexe Konfiguration zurückgeführt werden. Es muss somit angenommen werden dass keine optimale Konfiguration vorliegt. Squid 3 ist relativ schneller im Vergleich zu anderen Systemen aber im Vergleich zu Squid 2.7 langsamer. Ein Grund für dieses Verhalten könnte an der Reimplementierung des Squid liegen. Tabelle 1: Ergebnisse der Apache Benchmark Tests GeoWebCache kann nur Tiles einer bestimmten Größe übertragen, somit kann nicht jede Anfrage beantwortet werden. Dies führt dazu, dass im zweiten Testansatz ein Fehler produziert wird. Die Abbildungen zeigen, dass der Testserver die INSPIRE-Richtlinie zu 90 % innerhalb von 1,5 Sekunden für die definierten Kartengrößen erfüllt. In einer produktiven Umgebung sind die generierten Tiles deutlich kleiner als die spezifizierten 470 kb. Abbildung 1 zeigt die Performanz der Cache-Server in Hinblick auf die INSPIRE- Richtlinie, wie viel Prozent aller Anfragen in einem Zeitraum beantwortet werden können. Die Performanz Vorgaben der INSPIRE-Richtlinie wurde von allen getesteten Systemen, mit den definierten Kartengrößen erfüllt. Der Vergleich der Caching-Software zu der statischen Version der Tiles zeigt, dass die zur Verfügung stehende Hardware an ihre Grenzen stößt, im Besonderen die Bandbreite zwischen dem Server und dem Client. Dies wird durch den rasanten Anstieg der benötigten Zeit bei über 90 % der Anfragen verdeutlicht. Dieser Anstieg basiert auf Packet Kollisionen innerhalb des Transfer Stack des ISO-OSI Modells. Die maximal übertragbaren Bits der Netzwerk Verbindung für die angefragte Karte, das heißt die übertragene Datei Größe multipliziert mit der Anzahl gleichzeitiger Antwort, können die bereitgestellte Bandbreite nicht überschreiten. Diese liegt in diesem Testsetup bei 1 GBit. Eine höhere Bandbreite könnte die Zahl der Anfragen pro Sekunde erhöhen. Die Apache JMeter Ergebnisse (Abbildung 2) zeigen ähnliche Ergebnisse, wie die durchgeführten Apache Benchmark Tests. Alle Caching-Systeme erhöhen die Performanz der WMS-Anfragen. Squid und Varnish sind fast gleich schnell, während GeoWebCache und Apache mod_cache etwas langsamer sind.

9 Verschiedene Caching-Techniken für Web Map Services 199 Abb. 1: Ergebnisse der Apache Benchmark Tests im Vergleich zur INPIRE-Richtlinie ( px) Abb. 2: Ergebnisse JMeter Performanztests GeoWebCache ist direkt in den GeoServer integriert und damit an die durch den GeoServer bereitgestellten Daten gebunden. Tile-Caching-Systeme sind nicht an den OGC-WMS- Standard gebunden, sie verwenden einen eigenen Standard: Web Map Tile Service

10 200 A. Loechel und S. Schmid (WMTS). Generische HTTP-Caching-Systeme sind nicht an das Format der Anfrage oder des Antwort Dokument, bzw. den Web Service gebunden, sie können alle Inhalte cachen die mit dem HTTP-Protokoll konform sind. 7 Zusammenfassung und Ausblick Die Ergebnisse zeigen, dass Caching eines WMS möglich ist. Dabei wird die Performanz eines WMS-Servers signifikant erhöht. Caching bringt Vor- und Nachteile mit sich, welche in einer produktiven Umgebung bedacht werden müssen. Alle untersuchten Caching-Techniken zeigen eine Erhöhung der Performanz. Die Unterschiede der speziellen Geo-Tile-Caching-Systeme und der generischen HTTP-Caching- Systeme finden sich im Detail, wobei beide ihre Vorteile mit sich bringen. Das HTTP-Protokoll kombiniert mit den vorgestellten Cache Headern ermöglicht es standardkonformen Browsern und Shared Caches die Inhalte regelmäßig auf deren Aktualität zu überprüfen. Der Netzwerkverkehr wird durch den Einsatz von Caching deutlich reduziert, wodurch das System eine erhöhte Fehlertoleranz aufweisen kann. Ein Nachteil aller Caching-Systeme ist das Purge Problem. So ist es notwendig, dass die Caching-Software Änderungen an den Daten in einer angemessenen Zeit mitbekommt. Ein weiterer Nachteil der generischen HTTP-Caching-Systemen ist die Möglichkeit keine Daten im Voraus zu cachen. Inhalte werden erst bei der ersten Anfrage gecacht. Dies führt zu dem Problem, dass für einen sinnvollen Einsatz dieser Systeme immer die gleichen Anfragen gestellt werden müssen, was aber in einer normalen Umgebung die Regel ist. Tile Caching-Systeme können Tiles bereits im Vorfeld für bestimmte Bereiche generieren und sind flexibler bei der Interpretation der Anfrage. Weitere Studien müssen analysieren wo dieses Setup seine Limits erreicht hat: Squid Cluster könnten performanter sein als ein einzelner Server. Weiterhin müssen Algorithmen untersucht werden, die es ermöglichen Inhalte für generische HTTP-Caches im Voraus bereitzustellen. Literatur [1] PETERSON, M. P. (2008),. International perspectives on maps and the Internet. Springer, Berlin/New York. ISBN [2] FUI-HOON NAH, F. (2011), A study on tolerable waiting time: how long are Web users willing to wait? [3] EUROPEAN COMMISSION (2007), INSPIRE Network Services Performace Guidelines. European Commission. [4] OPEN GEOSPATIAL CONSORTIUM (2006), OpenGIS Web Map Server Implementation Specication. OGC European Commission. [5] BRADEN, R. (1989), Requirements for Internet Hosts { Application and Support. Internet Engineering Task Force, United States. [6] KERSKEN, S. (2006), Apache 2.2. Galileo Press GmbH, ISBN [7] DITHARDT, D. (2006), Squid. dpunkt Verlag. ISBN