[Mapserver-DE] Geschwindigkeit

[Arnulf Christl]

Marc Brünink wrote:
> Hallo,
> 
> ich frage mich, wie ich das Erzeugen der Karten etwas beschleunigen  
> kann. Im Moment habe ich 9 GB Shape Daten, die per shptree indiziert  
> wurden. Nun war mir der Gedanke gekommen, die Daten in ein PostGIS  
> System einzupflegen, um noch ein wenig Geschwindigkeit herauszupressen.  
> Wenn ich allerdings
> http://mapserver.gis.umn.edu/data2/wilma/mapserver-users/0301/ 
> msg00265.html
> lese, kommt PostGIS für mich eher nicht in Frage. Die Daten sind  
> statisch, mit den Attributen wir auch nicht viel  gemacht. Daher die  
> Frage: Lohnt sich der Umstieg? Die mail ist immerhin von 2003. Ist das  
> noch aktuell? Es scheint ja eher ein generelles Problem zu sein.

Hallo,
ich hatte mit Paul wegen dieser Frage schon ein paar Diskussionen, die 
letzte auf der OSG 05. Ich behaupte immer noch, dass Daten aus 
PG/PostGIS schneller sein können, als mehrere gekachelte Shape-Dateien. 
Vor allem, wenn es um sehr große Datenmengen geht. Prinzipiell ist es 
aber richtig, dass natürlich beim Shape-Dateizugriff nur ein 
Softwarepaket angeworfen wird, mit Datenbank aber zwei. Durch Fast-CGI, 
Festplatten Caches, viel RAM, etc. werden solche Überlegungen aber 
sowieso undurchschaubar.

Wirklich aussagekräftige und ausgeglichene Benchmarks sind deshalb nicht 
möglich, deswegen gibt es auch keine. Allein schon die Anforderung an 
die Hardware unterscheidet sich stark zwischen datenbank- und 
dateibasiertem Zugriff. Wenn man einen einzelnen Server verwendet, um 
beide Varainten zu testen berücksichtigt man z.B. den Architekurvorteil 
einer verteilten Installation nicht (z.B. Webserver auf extra Maschine). 
Wenn man ein sehr schnelles Netzwerk oder gar Zugriff auf ein SAN hat 
ändern sich wieder alle Grundparameter.

> Würde es helfen überflüssige Attribute aus den Daten zu entfernen? Wenn  
> ja, wie mache ich das dann?

In der Datenbank kann man die entsprechenen Spalten löschen, das ist 
sehr einfach. Für die Geschwindigkeit ist das nicht besonders relevant, 
da es die Indizes nicht betrifft, aber die Datenmenge reduziert sich 
natürlich. Nach umfangreichen Arbeiten in einer DB unbedingt nicht 
vergessen mit Vaccumm Analyze die Datenbank aufzuräumen.

> Gibt es sonst noch irgendwelche Tricks und Kniffe? Im Moment ist  
> Deutschland in 7 Arealen geteilt. Würde es vielleicht helfen, die Daten  
> in noch kleinere Areale zu zerlegen?

Wir empfehlen keine räumliche Zerlegung in Bereiche und erstellen lieber 
einen einzelnen, sauberen, indizierten zentralen Datenbankbestand. So 
ganz prinzipiell gesprochen...
Um was für Daten handelt es sich denn? Es kann sinnvoll sein, einen 
ausgedünnten Datenbestand für die Übersicht zu verwenden und erst beim 
reinzoomen auf Detaildaten zuzugreifen. Bei einer Deutschlandkarte z.B. 
können die Autobahnen als Schemazeichnung mit Punkten nur von Ausfahrt 
zu Ausfahrt mit reduzierter Stützpunktanzahl für die Übersicht verwendet 
werden. Erst wenn man unter Zoom xy kommt werden die Ausfahrten als 
eigene Kleeblätter und die Fahrbahnen als eigenen Geometrien 
dargestellt. Bei Shapedateien können die unterschiedlichen Zoomebenen 
dann als einzelne Dateien vorgehalten werden.

Wenn die Daten vollkommen statisch und ohne irgendwelche attributive 
Suche genutzt werden ist die Shape-Datei Variante aber auf jeden Fall 
diejenige, die mit dem geringsten Aufwand einhergeht, da man keine 
zusätzliche Installation der Datenbank benötigt. Sobald man etwas mehr 
machen will kommt man langfristig an der Datenbank aber eh nicht vorbei.

Es gibt weitere Fragen, die vor einer Architekturentscheidung gestellt 
werden sollten.
- Wie viele Zugriffe werden erwartet? (1-, 10-, 100Tausend / Tag)
- Wie viele Zugriffe erfolgen auf exakt den gleichen Ausschnitt? Das 
passiert wesentlich öfter als man denkt, vor allem, wenn die gesuchten 
Ausschnitte aus einer alphanumerischen Suche resultieren (Suche: Kölner 
Dom). Bei Stadtplandiensten erfolgen gut 70% aller Anfragen mehr als 
einmal, 60% aller Anfragen werden pro Monat mindestens 10 mal oder mehr 
angefordert. Bei solchen Zugriffsstatistiken macht es Sinn einen 
"intelligten" Proxy vorzuschalten, der getMap-Requests nur ein einzgies 
Mal wirklich an den Dienst schickt und alle weiteren Anfragen auf diesen 
Bereich aus dem Cache bedient. Das macht die Systeme bltzeschnell, 
ausser jeder einzelne Zugriff ist 100% eindeutig individuell und neu.

Andere Fragen betreffen die Ausgestaltung, müssen Label gesetzt werden 
(AUTO), werden Objekte mehrfach überlagert, um kartographische Effekte 
zu erzielen.

Viel Performance geht erfahrungsgemäß erst auf der letzten Meile flöten, 
also direkt vor und im Client. Wenn die Anbindung der Browser über 
Klingeldraht erfolgt, sollte man versuchen die Dateigröße zu minimieren 
(weniger Farbtiefe, anderes Format) oder differenziell nachzuladen 
(mehrere Ebeben, die parallel angefordert werden) und vor allem den JS 
und HTML Overhead im Client minimieren.

Vor einer Entscheidung würde ich also empfehlen die Anwendungsszenarien 
nochmal genau zu durchleuchten und dann bei einem Prototyp Meßpunkte zu 
setzen, die genaue Auskunft darüber geben wo im System der Flaschenhals 
eigentlich sitzt (Datenbank, MapServer, Webserver, Firewall, etc.).

hdh, Arnulf.

Hmmm - das sollte man mal als Thema im Wiki aufmachen, mir fallen 
dauernd noch mehr Sachen ein. Schade, dass MapServer kein eigenes Wiki 
mehr betreibt. Das neue Plone-CMS ist zwar schick, hat aber den üblichen 
Berechtigungs-Wasserkopf was dazu führt, dass keiner es benutzt.

> Vielen Dank
> Marc Brünink
> 
> _______________________________________________
> Mapserver-DE mailing list
> Mapserver-DE at freegis.org
> https://freegis.org/mailman/listinfo/mapserver-de