Benchmarking deegree WMS

Transkript

1 Benchmarking deegree WMS Lydia GIETLER 1 Einleitung Beim Aufbau von Internetlösungen zur Präsentation von Geodaten empfiehlt sich in bestimmten Fällen der Einsatz von Open Source-Produkten, vorausgesetzt diese sind mit der Spezifikation für Web Mapping Services (WMS) des Open GIS Consortium (OGC) konform. Aufgrund der geringen Lizenzkosten ist der Einsatz solcher Open Source-Produkte für klein- und mittelständische Betriebe, Start-Up-Unternehmen, Non-Profit-Organisationen aber auch für Kommunen interessant. Ist die Entscheidung für den Einsatz eines Open Source-Produktes für einen derartigen Zweck getroffen, steht man vor der Wahl, aus den Produkten dasjenige auszuwählen, das den Bedürfnissen der Anwendung sowie der Nutzer genügt. Die Nutzerakzeptanz und damit der Erfolg eines Web Mapping Services hängen neben weiteren Aspekten wie z. B. einem ansprechenden User-Interface von der Performance des Servers ab. Open Source-Produkte für OGC konforme Web Mapping Services werden von verschiedenen Entwicklern frei zur Verfügung gestellt. Ein Beispiel dafür ist der deegree WMS, ein Java Framework zur Implementierung von Web-basierten GIS-Applikationen, das von der Universtät Bonn gemeinsam mit der Firma lat/lon entwickelt wurde und auf zum Download bereit steht. OGC konforme Web Mapping Services stellen in einem Rendering-Prozess Karten aus verschiedenen Datenbasen (Layern) entsprechend der in der Serveranfrage (Request) angeführten Parameter. Die Geschwindigkeit, mit der ein spezieller Server Karten rendern kann, ist abhängig von der Größe der Datenbasis sowie der Anzahl der gleichzeitigen Zugriffe. In dieses Paper berichten wir über die Abhängigkeit der Performance des deegree WMS von der Anzahl der gleichzeitigen Zugriffe sowie der Größe der Datenbasis am Beispiel von ESRI Shapefiles. 2 Problemstellung Die Antwortzeit eines Web Mapping Services ist die Dauer zwischen der Anforderung der Karte, etwa durch Mausklick, und der Darstellung der Karte am Bildschirm des Client. Diese Zeit setzt sich zusammen aus der Dauer der Übertragung der Daten über das Internet, einer eventuellen Wartezeit am Server, der Dauer, die der Server zur Erzeugung der Karte benötigt, sowie der Zeit, die das System der User zur Darstellung benötigt. Aufgrund der vom Applikationsprovider nicht beeinflussbaren Dauer der Datenübertragung über das Netz (NIELSEN 2004) sowie der vernachlässigbaren Größe der Darstellungszeit besteht Bedarf, die Dauer vom Eintreffen einer Anfrage am Server bis zur Ausgabe der Response vom Server ins Netz zu optimieren.

2 Benchmarking deegree WMS 173 Die Kenntnis über das Antwortzeitverhalten von Servern in Abhängigkeit von verschiedenen Parametern ermöglicht es, bei der Planung von Applikationen die Einsetzbarkeit dieser Produkte abzuschätzen. Ist die Entscheidung für den Einsatz eines bestimmten Produktes bereits getroffen, ermöglichen es derartige Kenntnisse, die genannten Parameter hinsichtlich einer maximalen Antwortzeit zu optimieren. 3 Die Testumgebung Die Tests werden in einem abgeschlossenen Netzwerk mit einer Übertragungsleistung von 100 MBit/sek durchgeführt (Abbildung 1). Als Hardware für den deegree WMS dient ein Standard-PC mit einem Intel Pentium 4 Prozessor mit 2,4 GHz und 512 MB Hauptspeicher. Als Client-Rechner, der für derartige Tests wegen der Aufzeichnung und Evaluierung der Ergebnisse höher dimensioniert sein muss als der Server, wird eine Workstation mit zwei Intel Xeon Prozessoren mit je 2,4 GHz und zwei GB Hauptspeicher benutzt. Die beiden Rechner sind durch einen 100 MBit Switch miteinander verbunden. Abb. 1: Die Architektur der Testumgebung Für die Tests wurde die vorkonfigurierte Demoversion des deegree WMS installiert. Das Kernstück dieser Software, die deegree.jar Datei, wurde durch ein Update vom Februar 2004 ersetzt. Von Apache Tomcat kam die Version zum Einsatz. Als Betriebssystem am Server kommt Microsoft XP zum Einsatz. Da der Rechner als dezidierter Server fungiert, wurden sämtliche überflüssigen Dienste deaktiviert und keine weitere Software installiert. Um der weit verbreiteten Meinung, Open Source-Produkte wären sowohl im Setup als auch in der Wartung aufwändiger und benötigten mehr Know-how vom Systemadministrator als kommerzielle Produkte entgegenzuwirken, werden für die vorliegenden Untersuchungen sowohl die Installation als auch die Optimierungen entsprechend der Dokumentationen des deegree Frameworks berücksichtigt (deegree, 2003a; deegree, 2003b). Auch wurden für

3 174 L. Gietler diese Tests keine Veränderungen am Source Code vorgenommen, sondern vorkompilierte Releases benutzt. Um das Zeitverhalten des deegree WMS zu testen, wurden per Zufallsgenerator Daten erzeugt. Ursprünglich wurde ein Shapefile mit punkthaften, ein weiteres mit linienhaften und ein drittes mit flächenhaften Objekten erzeugt. Diese wurden in insgesamt neun Schritten jeweils verdoppelt und ebenfalls wieder in Shapefiles gespeichert. Sämtliche Shapefiles wurden, sofern möglich, mit RTree-Indices versehen, die mit einer Funktion des deegree Frameworks erzeugt wurden. 4 Die Tests Als Testwerkzeug steht Apache JMeter, eine freie Software, die unter anderem zur Durchführung von Benchmark-Tests genutzt werden kann, zur Verfügung. Die erzeugten JMeter Testpläne umfassen je drei Kartenanfragen, so genannte GetMapRequests. Diese Requests enthalten Parameter, die unter anderem die Bounding Box der gewünschten Karte sowie eine Liste der Layer, aus der die Karte generiert wird, bezeichnen. Durch unterschiedliche Bounding Boxes in den drei Requests wird Zoom und Pan simuliert. Insgesamt neun verschiedene Testpläne erlauben durch unterschiedliche Dreier-Kombinationen der Layer den Zugriff auf die unterschiedlich großen Datenbasen (siehe Tabelle 1). Es wurden Karten in der Größe von 450 x 450 Pixeln im jpeg-format erstellt, das ergibt eine Ausgabegröße von durchschnittlich 80 kb pro Karte. Tabelle 1: Die Datenbasen der Testpläne Name des Testplanes Anzahl der Punkte Anzahl der Linien Anzahl der Flächen Summe der Objekte WMSTest_ WMSTest_ WMSTest_ WMSTest_ WMSTest_ WMSTest_ WMSTest_ WMSTest_ WMSTest_ Innerhalb eines Testplanes werden die drei GetMap Requests, jeweils nach Ankunft der Response der vorhergehenden Anfrage, an den Server gesandt. Dies wird fünf Minuten lang wiederholt. Die Antworten werden kategorisiert nach Erfolg, also Erhalt einer korrekten Karte, bzw. Misserfolg. Die Anzahl der erhaltenen Karten wird auf korrekte Karten pro Stunde hochgerechnet. Die unterschiedliche Anzahl gleichzeitiger Zugriffe wird von Apache JMeter durch Starten mehrerer Threads, die jeweils dieselbe Aufgabe erfüllen, simuliert. Diese unterschiedliche Anzahl von n Threads pro Testdurchgang wird jeweils innerhalb einer Sekunde gestartet,

4 Benchmarking deegree WMS 175 was für den Server den Erhalt von n GetMap Requests innerhalb einer Sekunde bedeutet. Die Anzahl der Threads wird für jeden Testplan in Zweierpotenzschritten erhöht, bis die Fehlerrate 50 % übersteigt. 5 Die Ergebnisse Die Ergebnisse der Tests zeigen eine deutliche Abhängigkeit der Anzahl der korrekt produzierten Karten von der Größe der Datenbasis sowie der Anzahl der gleichzeitigen Zugriffe. In den Abbildungen 2 und 3 werden die genauen Werte der Untersuchungsergebnisse visualisiert. Zur besseren Veranschaulichung wurde zwischen den Hochrechnungen der gemessenen Werte interpoliert. Karten pro Stunde in Abhängigkeit der Anzahl der gleichzeitigen Zugriffe Karten pro Stunde Anzahl der Threads WMSTest_1 WMSTest_2 WMSTest_3 WMSTest_4 Abb. 2: Visualisierung der Testergebnisse für die Tests 1 bis 4

5 176 L. Gietler Karten pro Stunde in Abhängigkeit der Anzahl der gleichzeitigen Zugriffe Karten pro Stunde Anzahl der Threads WMSTest_5 WMSTest_6 WMSTest_7 WMSTest_8 WMSTest_9 Abb. 3: Visualisierung der Testergebnisse für die Tests 5 bis 9 6 Diskussion Die genauen Werte der Ergebnisse stellen keinen Diskussionspunkt dar, weder für einen Vergleich mit Konkurrenzprodukten noch für oder gegen den Einsatz des deegree WMS für eine bestimmte Applikation. Dies liegt daran, dass Unterschiede in der Hardware und der Konfiguration des Systems andere Werte ergeben würden. Man kann allerdings feststellen, dass sich eine Kachelung der Daten anstelle einer großen Datenbasis beim Einsatz des deegree WMS empfiehlt. Zur genauen Abschätzung der Größe der Dateien für einzelne Applikationen muss eine Voraussage über die erwartete Anzahl von gleichen Zugriffen gemacht werden und dementsprechend das Gesamtsystem konzipiert werden. Des Weiteren wurden in den vorliegenden Tests die Übertragungsdauer der Daten über das Netz vernachlässigt. Entsprechende Überlegungen hinsichtlich der Geschwindigkeit der Netzwerkanbindung der User müssen in eine Applikationsplanung einfließen. Hierbei kann

6 Benchmarking deegree WMS 177 z. B durch Herabsetzen der Parameter für die Kartengröße in Pixeln Zeit eingespart werden. Auch muss serverseitig genügend Bandbreite zur Verfügung stehen. Die räumliche Indizierung der Shapefiles verspricht schnelleren Zugriff auf einzelne Features. Zum Indizieren der Dateien für die vorliegenden Tests wurde eine Funktion des deegree Frameworks benutzt, die zu diesem Zeitpunkt noch nicht völlig ausgereift war. Daher gelang die Indizierung, ohne den Veränderungen am Source Code durchzuführen, nur für linienhafte und punkthafte Objekte. Abschließend lässt sich bemerken, dass der deegree WMS unter Berücksichtigung der hier dargelegten Bemerkungen sowie der in seiner Dokumentation erläuterten Konfiguration auch auf Standardhardware durchaus akzeptable Antwortzeiten erzielt. 7 Ausblick Diese Tests sind Teil meiner Diplomarbeit, in deren Rahmen ähnliche Tests auch für Open Source-Implementierungen von OGC konformen Web Feature und Web Coverage Services durchgeführt werden. Um Vergleiche mit anderen Produkten zu ermöglichen, werden sämtliche Tests, die dabei benutzten Daten und die von mir erzielten Ergebnisse ab September 2004 auf zum Download angeboten. Danksagung Ich bedanke mich bei Herrn Prof. Dr.-Ing. Wolfgang Reinhardt von der Arbeitsgemeinschaft GIS an der Universität der Bundeswehr München, der es mir ermöglicht hat, diese Tests sowie weitere im Rahmen meiner Diplomarbeit durchzuführen. Mein Dank geht auch Herrn Dr.-Ing. Gerhad Joos, der mir bei der Erzeugung der Testdaten behilflich war. Literatur NIELSEN, J. (2004): The Need For Speed Update January 2004: Still Mostly Slow. DEEGREE (2003a): deegree Web Map Server. DEEGREE (2003b): deegree Web Feature Server.