[Mapserver-DE] Bessere Performance. Wie?

[Titus von der Malsburg]

On Wed, Sep 22, 2004 at 03:45:57PM +0200, Frank Koormann wrote:
> Auch auf shapefile-Ebene lassen sich indices erstellen, siehe dazu
> shpindex aus dem MapServer-Paket. Rasterkarten lassen sich ggf. in Tiles
> zerlegen, mit tile4ms lassen sich auch hier indices aufbauen.

Ich mache mit meinen Rasterdaten folgendes:

 1. in Kacheln zerschnipseln
 2. Farbtiefe soweit möglich reduzieren
 3. falls noch nicht geschehen nach GEOTiff konvertieren
 4. "Overviews" errechnen.

Overviews sind Versionen des Rasterbildes in geringerer Auflösung.  Wenn
man GEOTiffs verwendet können diese Overviews und das urspüngliche
Rasterbild in einer GEOTiff-Datei gespeichert werden, was den Vorteil
hat, dass man nicht mit so vielen Dateien hantieren muss.  Das Ergebnis
nennt man glaube ich Pyramide.  Der Witz ist jetzt, dass wenn der
Mapserver zum Rendern nicht die Monsterauflösung braucht, er sich aus
dieser Pyramide einfach die Version mit der passensten Auflösung
raussucht.  Das kann das Rendern von großen Ausschnitten
erheblich beschleunigen.

Dieses Verfahren ist komplementär zu der Sache mit den Kacheln.  Die
Kacheln machen, dass man nicht alle Daten laden muss, wenn nur ein
kleiner Ausschnitt gezeigt wird, und die Pyramiden machen, dass nicht
die volle Auflösung verwendet werden muss, wenn der Ausschnitt groß ist.

Diese Overviews erzeugt man so:
	
	gdaladdo bild.gtiff 2 4 8 16

Dabei geben die Zahlen an in welchen Stufen Overviews erzeugt werden
sollen.

Meine Vermutung bzgl. der Kompression der Bilddateien ist übrigens, dass
die Kompression eher hilft statt schadet.  Zwar muss das Bild zusätzlich
dekodiert werden, dafür muss aber weniger von der Festplatte gelesen
werden (wenn man natürlich so wenig Rasterdaten hat, dass alles ins
Cache passt, isses umgekehrt; aber das wird eher selten der Fall sein).
Und von Festplatte lesen geht i.A. _viel_ langsamer als ein bisschen mit
der Multigigaherz-CPU rumzurechnen.  Ausserdem ist der
Kompressionsalgorithmus der Tiffs (lzw, oder?) ziemlich billig was
CPU-Zeit angeht.  Mit JPEGs mag das anders sein.  Hat das jemand mal
gestestet?

Und noch eins, irgendwie scheint die Vermutung rumzugeistern, dass durch
irgendeine Magie Vektordaten schneller aus dem PostGIS gelesen werden,
als aus SHP-Dateien.  Ich verwende zwar kein PostGIS und kann's deswegen
nicht aus eigener Erfahrung berichten, aber ich hab jetzt schon von
mehrern Leuten Hinweise bekommen, dass PostGIS eher langsamer als
SHP-Dateien ist (wahrscheinlich wegen dem ganzen Datenbankoverhead, den
man bei den nackten Dateien nicht hat).  Ich glaube es gab dazu mal
einen Thread auf einer der englischen Mailinglisten.  Auf jeden Fall gab
es ein paar Leute bei denen PostGIS schneller war und und wo sich
später herausgestellt hat, dass ihre SHPs keine Indices hatten -> kein
Wunder.

Ausserdem:  Der Linuxkernel bietet eine Option, die vielleicht für
Mapservers Performanz positive Auswirkungen haben könnte.  In Kernel 2.6
kann man statt dem antizipatorischem IO-Scheduler (default) den Deadline
IO-Scheduler wählen.  Während der antizipatorischem eher für den
Desktopeinsatz optimiert ist, scheint der Deadline für
Datenbankanwendungen mit großem Durchsatz besser zu sein.  Aus der
Dokumentation:

	Database servers, especially those using "TCQ" disks should
	investigate performance with the 'deadline' IO scheduler. Any system
	with high disk performance requirements should do so, in fact.

U.s.w.

Hab ich allerdings auch nicht ausprobiert :-(

Viele Grüße,
	Titus


> Weitere Möglichkeit: Für bestimmte Zoomstufen ggf. vereinfachte
> Datenbestände aufbereiten.