OpenLayers.js: Performancetuning

daniel_ · 2010-10-19 10:22:45

Hallo!

Nachdem ich nun mit der Entwicklung meines kleinen Kartenprojektes mit Hilfe von OSM/ Openlayers großteils fertig bin geht es nun an das Performancetuning. Bisher hatte ich nur einen Link zur aktuellsten Version von Openlayers (http://www.openlayers.org/api/OpenLayers.js) eingebunden, was aber aufgrund der Größe des Skripts für den Produktiveinsatz viiieeel zu lange zum Laden braucht. Jetzt hab ich mich auch schon ein bisschen umgesehen und gehört, dass man sich eine eigene angepasste Version des Skripts erstellen kann, das nur die nötigsten Teile beinhaltet. Dieses würde ja dann auf dem eigenen Server liegen und nicht mehr bei OpenLayers.

Genau das wirft für mich nun die Frage auf, wie es in diesem Fall nun mit Aktualisierungen aussieht. Würde man den Link wie oben angegeben einbinden, hätte man ja immer die aktuellste Version und wäre damit "auf der sicheren Seite". Sofern man nicht ständig manuell aktualisieren möchte, hat man vermutlich bald einmal eine veraltete Version. Wäre es dann nicht auch möglich, dass eine bestimmte Funktionalität plötzlich gar nicht mehr funktioniert (z.B. weil sich bei OSM was geändert hat, was in der alten OpenLayers-Version noch nicht berücksichtigt wird, etc.)? Wie löst ihr dieses Problem?

Danke und LG
Daniel

wambacher · 2010-10-19 10:34:28

hi,

alles hat seinen preis: hier größe versus aktualität.

meine "lösung": download von der quelle, kein eigenes file
grund: download-zeiten sind nicht mehr sooo kritisch

zum 2. punkt: osm und openlayers haben fast nichts miteinander zu tun - bis auf diese kleine osm-spezifische source. es bestehen da keinerlei probleme, da openlayers osm garnicht "kennt".
wir können nix in osm einbauen sodaß ol nicht mehr läuft.

gruss
walter

t-i · 2010-10-19 13:18:44

Script-Minimalizer: http://openlayerer.appspot.com/

@Geschwindigkeit: Falls der ein Besucher schon vorher auf einer OSM-Seite war, ist die Wahrscheinlichkeit gross, dass er das Script bereits im Cache hat - insofern sollte die Geschwindigkeit nur beim ersten Besuch eine Rolle spielen. Allerdings ist OpenLayers.org immer mal wieder down - mir ist daher meine private Kopie auf meinem Server auch lieber.

@Aktualität: Hier ist es eher umgekehrt: bei neuen OL-Versionen werden teilweise alte Funktionen entfernt, d.h. Deine Karte könnte mit einer neuen Version plötzlich(*) nicht mehr funktionieren. Da OL einen 'geringen' Funktionsumfang hat (keine Veränderungen an Daten auf dem Server), sind mir keine kritischen Sicherheits-Probleme bekannt, die in der Vergangenheit geschlossen werden mussten.

Wie Walter bereits gesagt hat: eine heute funktionierende Lösung mit lokalem OL-Script wird wohl auch in Zukunft unverändert funktionieren.

[Das Einzige was mir hier einfallen würde, wäre der Speicherort der Tiles, aber dessen Änderung wäre wohl noch mehr Protesten aus der Community verbunden wie der Wechsel der Lizenz. :->]

(*) 'plötzlich' im Sinne von: Die Funktion wird als deprecated markiert und irgendwann beim überüberübernächsten Release nicht mehr integriert.

amm · 2010-10-19 13:36:10

t-i hat die Vorteile einer lokalen Kopie von OL ja eigentlich schon sehr gut beschrieben. Da wollte ich nur kurz ergaenzen, das OSM deshalb im uebrigen auch eine lokale Kopie hat, und zwar eine die nur das noetigste enthaelt um die Geschwindigkeit zu optimieren.

Wenn ich mich richtig erinnere, ist es in der Vergangenheit auch schon vorgekommen das ein Update von OL existierenden Karten Probleme bereitet hat (oder war das ein update der openstreetmap.js?), also nicht nur erst beim ueberuebernaechsten release.

maxbe · 2010-10-19 14:33:28

Ich glaube, es ist sehr wahrscheinlich, dass eigene Openstreetmap-Anwendungen durch einen Openlayers-Versionswechsel plötzlich nicht mehr gehen.

Z.B. werden alle Seiten mit MouseDefaults eines Tages Probleme machen. Das schon lange als "deprecated" gekennzeichnet, wird aber trotzdem fleissig verwendet. Teils weil man das wirklich braucht, häufiger weil man Beispielcode irgendwo kopiert.

Viele wird ein Wegfall nicht stören, das kann fast immer durch Control.Navigation ersetzt werden, aber die Fehlersuche ist halt lästig und kommt sicher dann gerade ungelegen.

wambacher · 2010-10-19 17:18:51

aus dem gleichen grunde würde ich zumindest bei neueren anwendungen oder geplanten "renovierungsarbeiten" ab sofort auf MARKER verzichten. markers ist (fast) tot. der neue könig heisst VECTOR.
vectors kann als superset alles was markers auch kann.
gruss
walter

wyo · 2010-10-19 20:20:37

wambacher wrote:

vectors kann als superset alles was markers auch kann.

Danke für den Hinweis. Welches Beispiel auf OpenLayers eignet sich als Anschauungsunterricht? Die Informationen weches Beispiel für welches Feature geeignet ist fehlen auf OpenLayers komplett.

Wyo

wyo · 2010-10-19 20:28:17

amm wrote:

t-i hat die Vorteile einer lokalen Kopie von OL ja eigentlich schon sehr gut beschrieben.

Eigentlich sollte die lokale Kopie Standard sein, eine im produktiven Einsatz, eine im Testverzeichnis. So kann man in Ruhe eine neue Version austesten.

amm wrote:

OSM deshalb im uebrigen auch eine lokale Kopie hat, und zwar eine die nur das noetigste enthaelt um die Geschwindigkeit zu optimieren.

Ich halte es für keine geschickte Idee, wenn jeder seine eigene optimierte Version erstellt. Bei einer 1MB grossen Datei wäre es angezeigt, sie in ein Basismodul und mehrere Erweiterungen aufzuteilen. Dann kann jeder das laden, was er für seine Seite benötigt.

Wyo

wambacher · 2010-10-19 21:22:31

wyo wrote:

wambacher wrote:
vectors kann als superset alles was markers auch kann.
Danke für den Hinweis. Welches Beispiel auf OpenLayers eignet sich als Anschauungsunterricht? Die Informationen weches Beispiel für welches Feature geeignet ist fehlen auf OpenLayers komplett.
Wyo

die sind leider noch knapper als die marker-beispiele. wenn man vector aber erst gepackt hat, ist es relatiov einfach, die marker-beispiele abzuleiten.
ist etwas so, wie mit der ol-api. die "doku" versteht man erst, wenn man sich ganz genau mit ol auskennt ich lese mir die api-dok und viele demos einfach alle 3-4 wochen neu durch und plötzlich "funkt es".

wyo · 2010-10-19 21:41:25

wambacher wrote:

ist etwas so, wie mit der ol-api. die "doku" versteht man erst, wenn man sich ganz genau mit ol auskennt ich lese mir die api-dok und viele demos einfach alle 3-4 wochen neu durch und plötzlich "funkt es".

Ich bin im Moment auch gerade am kreuz und quer lesen, so suche ich momentan die Klassendefinition eines Click-Event resp. welche Parameter das Trigger-Element hat. Unmöglich da etwas zu finden, für heute gebe ich auf.

Wyo

!i! · 2010-10-19 22:26:04

Ja OL hat das etwas ungeschickt mit den Examples, aber so steigst du durch: http://dev.openlayers.org/releases/Open … -list.html
Ansonsten gefällt mir das Buch zu OL ganz gut, denke für die meisten Sachen die man so im normalen Rahmen macht ist das erstmal ausreichend.

Wie bekommt man eigentlich mit was dort als veraltet markiert ist?

wambacher · 2010-10-19 23:26:50

!i! wrote:

Wie bekommt man eigentlich mit was dort als veraltet markiert ist?

durch ausdauerndes und andächtiges lesen

bei marker/vectors stand *irgendwo* (in einem beispiel?) drin, dass man besser vectors nehmen soll, weil nur vectors weiter verbessert wird. aber so ne "depreciated-liste" kenn ich auch nicht.
war also reiner zufall.
war echt blöd, dass ich am anfang code-snipsel aus markers- und vectors-beispielen gemixt hatte ohne das zu merken
gruss
walter

wyo · 2010-10-20 07:09:03

!i! wrote:

http://dev.openlayers.org/releases/Open … -list.html

Das habe ich auch schon probiert, aber such mal nach "MousePosition", bei mir kommen keine Resultate.

Wyo

daniel_ · 2010-10-20 14:55:06

Danke euch allen für die vielen Antworten. Ich werde dann wohl doch eine lokale modifizierte Version des Skripts bereitstellen.

Jetzt nur noch eine Frage dazu: Wie weiß man denn, welche Einzeldateien genau included werden müssen? Natürlich, einmal alle welche in der eigenen Seite direkt referenziert werden (mittels new-Operator oder dergleichen), das ist klar. Aber darüber hinausgehend? Ich habe nämlich ein Projekt mit Vector-Markierungen und es funktioniert auch alles, bis auf die Tatsache, dass die Vector-Objekte immer exakt in der Kartenmitte platziert werden, obwohl eine andere Position angegeben wurde. Steht hingegen die vollständige Library zur Verfügung funktioniert das einwandfrei. Ich bekomme allerdings keinen JavaScript-Fehler in IE.

Kann man das nur durch Ausprobieren herausfinden oder gibt es auch einen anderen Weg?

Danke und LG
Daniel

EvanE · 2010-10-20 15:59:02

daniel_ wrote:

Danke euch allen für die vielen Antworten. Ich werde dann wohl doch eine lokale modifizierte Version des Skripts bereitstellen.
Jetzt nur noch eine Frage dazu: Wie weiß man denn, welche Einzeldateien genau included werden müssen? Natürlich, einmal alle welche in der eigenen Seite direkt referenziert werden (mittels new-Operator oder dergleichen), das ist klar. Aber darüber hinausgehend? Ich habe nämlich ein Projekt mit Vector-Markierungen und es funktioniert auch alles, bis auf die Tatsache, dass die Vector-Objekte immer exakt in der Kartenmitte platziert werden, obwohl eine andere Position angegeben wurde. Steht hingegen die vollständige Library zur Verfügung funktioniert das einwandfrei. Ich bekomme allerdings keinen JavaScript-Fehler in IE.
Kann man das nur durch Ausprobieren herausfinden oder gibt es auch einen anderen Weg?

Hallo Daniel

Du könntest einen anderen Browser wie Firefox oder
Opera um nur einige Verbreitete zu nennen ausprobieren.

Die zeigen vielleicht doch Fehler an.

Edbert (EvanE)

wicking · 2010-10-20 19:29:27

daniel_ wrote:

Version von Openlayers (http://www.openlayers.org/api/OpenLayers.js) eingebunden, was aber aufgrund der Größe des Skripts für den Produktiveinsatz viiieeel zu lange

Hast Du mal alternativ khtml.org versucht? Die lib ist viel kleiner und die Leistung beim Betrachten („performance") mit aktuellen (teils noch Beta) Browsern viel höher.

Wäre zumindest eine Überlegung wert, denke ich.

Announcement

#1 2010-10-19 10:22:45

OpenLayers.js: Performancetuning

#2 2010-10-19 10:34:28

Re: OpenLayers.js: Performancetuning

#3 2010-10-19 13:18:44

Re: OpenLayers.js: Performancetuning

#4 2010-10-19 13:36:10

Re: OpenLayers.js: Performancetuning

#5 2010-10-19 14:33:28

Re: OpenLayers.js: Performancetuning

#6 2010-10-19 17:18:51

Re: OpenLayers.js: Performancetuning

#7 2010-10-19 20:20:37

Re: OpenLayers.js: Performancetuning

#8 2010-10-19 20:28:17

Re: OpenLayers.js: Performancetuning

#9 2010-10-19 21:22:31

Re: OpenLayers.js: Performancetuning

#10 2010-10-19 21:41:25

Re: OpenLayers.js: Performancetuning

#11 2010-10-19 22:26:04

Re: OpenLayers.js: Performancetuning

#12 2010-10-19 23:26:50

Re: OpenLayers.js: Performancetuning

#13 2010-10-20 07:09:03

Re: OpenLayers.js: Performancetuning

#14 2010-10-20 14:55:06

Re: OpenLayers.js: Performancetuning

#15 2010-10-20 15:59:02

Re: OpenLayers.js: Performancetuning

#16 2010-10-20 19:29:27

Re: OpenLayers.js: Performancetuning

Board footer