[Mapserver-DE] Bessere Performance. Wie?
Hubert Fröhlich
hubert.froehlich at bvv.bayern.de
Don Sep 23 08:05:09 CEST 2004
Titus von der Malsburg wrote:
> Meine Vermutung bzgl. der Kompression der Bilddateien ist übrigens, dass
> die Kompression eher hilft statt schadet. Zwar muss das Bild zusätzlich
Entspricht gerade bei großen und hoch auflösenden Rasterdatenbeständen
(Digitale Orthophotos!) ziemlich genau NICHT meiner Erfahrung
> 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?
Am vorteilhaftesten scheint mir zu sein, die Bildateien in TIFF (GEOTIFF
auch, hat organisatorische Vorteile) abzulegen, aber unbedingt ***
UNcompressed ***. Das ist zwar ein Faktor 5 gegenüber JPEG, aber
DEUTLICH schneller.
Dürfte damit zu tun zu haben, dass man auf TIFF uncompressed auch
"random" zugreifen kann, d.h. für Bildausschnitte (Regelfall) nicht das
ganze Bild lesen muss - oder so ähnlich - stimmt das so, wie ich das
darstelle?! Dieser Effekt geht bei jeder Art von Kompression natürlich
verloren.
Wo man etwas rumexperimentieren muss, ist bei der Bestimmung der
optimalen Kachelgröße beim Zerschnipseln des Datenbestandes, um ein
Optimum zu finden.
Wie gesagt, dann schafft man es auch, Orthophotos für ganz Bayern (40
000 km^2, 40 cm Bodenauflösung hochzuziehen :-)
>
> 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.
>
hmmm, meine Einschätzung: Bei großen Datenbeständen scheint Postgis
schneller zu sein, jedenfalls nach meinen bisherigen Erfahrungen
(mehrere Mio Polygone, 1 Postgis-Table vs. 80 Shapefiles mit Index, also
relativ konservativ gemacht) . Kann das jemand bestätigen/widerlegen?
(
> 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.
>
>
Hört sich interessant an, wer weiß darüber was?
Gruß Hubert
--
-------------------------------------------------------------------------------
Dr.-Ing. Hubert Fröhlich
Bezirksfinanzdirektion München
Alexandrastr. 3, D-80538 München, GERMANY
Tel. :+49 (0)89 / 2190 - 2980
Fax :+49 (0)89 / 2190 - 2997
hubert dot froehlich at bvv dot bayern dot de
This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)