PanoTour mit Scenes - langsamer Start?

  • Hi,


    ich habe grade meine erste Tour unter Nutzung von Scenes fertig gestellt. Local auf dem eigenen Rechner ging alles gewohnt schnell. Nachdem ich das aber geuploadet habe und testen wollte, ist mir aufgefallen, dass die Ladezeit extrem hoch geht.

    Es dauert mehrere Sekunden bis das preview des ersten Panos geladen wird. Einen freund nen Link gegeben, der hat 16k DSL und dennoch hats 5-6 Sekunden gebraucht eh überhaupt was angezeigt wurde. Das ist ja mittlerweile tödlich, solange wartet ja heutzutage keiner mehr. Lädt man hingegen das "StartPanorama" allein, dann geht es bedeutend schneller.


    Nun stellt sich mir die Frage:

    Woran liegt das?

    - Kann es sein, das das einbinden von XML-Dateien über include-Url alles andere als günstig ist? Sollte man vielleicht auch wenn dadurch die übersichtlichkeit flöten geht, jede XML-Datei in die eine finale Tour-XML kopieren? scheinbar wird erstmal überprüft, ob die dateien überhaupt da sind.... schön und gut, aber scheinbar extrem inperformant.

    - Werden eventuell auch die anderen Preview-Stripes vorgeladen?

    Hier mal der Quellcode der Tour:


    oder ist da etwas inperformantes drin?


    ISt das normal, dass diese Art der Tourerstellung unter diesen tödlichen Nachteil leidet?


    Danke für eine Antwort!

  • ich habe mal das selbe unter nutzung von loadpano anstatt loadscene gemacht und da geht es bedeutend schneller.


    da werde ich also aufgrund dieser massiven Performance-Unterschieden auf die loadpano-art-und-weise zurückgreifen werde, obwohl die Variante mit Scene nach den anfänglichen KO-Nachteil eher vorteilig und besser zu sein scheint. Viell kann man ja dieses Startverhalten noch optimieren mit einem der nächsten Releases... schön wärs :)

  • Ich habe mir Deinen Code jetzt nicht durchgelesen, will aber nur mitteilen, daß es bei mir ohne jegliche Verzögerung funktioniert (und wohl auch bei allen anderen, sonst hätte sich längst schon jemand beschwert...).
    Wär ja auch noch schöner, wenn das nicht funktionieren würde... *wink*

    Theo

  • Was ich nicht ganz überblicke bei Deinem Code-Ausschnitt:

    Hast Du etwa für jede Szene eine eigene xml-Datei angelegt? Falls ja, dann würdest Du ja den Sinn des scene-tags ad absurdum führen, der ja gerade darin besteht, mehr als nur ein einziges Panorama in eine xml-Datei schreiben zu können.

    Eine xml-Datei innerhalb einer Szene zu inkludieren ist in diesem Fall auch nicht sinnvoll, da sie ja erst nach Aufruf der Szene geladen wird.
    Inkludiere sie grundsätzlich innerhalb der Basis-xml, dann ist alles da, sobald Du es brauchst.

    Das nur mal so als Schnellschuss... *wink*

  • nuja, das resultiert einfach daraus, dass ich die einzelnen Panos schon soweit fertig online hatte und ich einfach die Dateien so eingebunden hab. ich probiers einfach nochmal so aus, das ich die in die eine XML-Datei kopiere...


    EDIT: Das einbinden der einzelnen XML ist scheinbar dieser Performance-Killer. nachdem ich die Dateien reinkopiert habe (und 1h nach einen dummen fehler gesucht habe ;) ) geht das nun recht fix. Das ganze ist aber trotzdem recht blöd, da man so gezwungen ist, die ganze sache in einer XML-Datei zu speichern. Jeder Versuch die Übersicht zu waren, indem man die einzelnen Panos in eigene XML-Dateien auslagert wird dadurch zu tote verurteilt... das ist schade. Ich hoffe, dass dieses Problem bei einem der nächsten Releases verbessert wird. (wenns denn geht)


    "Include Url" in KRPano 1.8.0.11 ist extrem inperformant!

    Edited 3 times, last by henryk86 (August 21, 2010 at 3:18 AM).

  • Was ich nicht ganz überblicke bei Deinem Code-Ausschnitt:

    Hast Du etwa für jede Szene eine eigene xml-Datei angelegt? Falls ja, dann würdest Du ja den Sinn des scene-tags ad absurdum führen, der ja gerade darin besteht, mehr als nur ein einziges Panorama in eine xml-Datei schreiben zu können.

    Eine xml-Datei innerhalb einer Szene zu inkludieren ist in diesem Fall auch nicht sinnvoll, da sie ja erst nach Aufruf der Szene geladen wird.
    Inkludiere sie grundsätzlich innerhalb der Basis-xml, dann ist alles da, sobald Du es brauchst.

    Das nur mal so als Schnellschuss... *wink*

    das stört doch nicht, wenn die Szene erst dann geladen wird, wenn die Szene auch ausgewählt wird. Das Problem ist ja auch nicht die Ladezeit zwischen den einzelnen Panos, sondern die Startladezeit bis überhaupt irgendwas angezeigt wird. Mittlerweile bin ich überzeugt, dass diese lange Startladezeit zwar in der Nutzung der include url-Funktion begründet liegt, jedoch nicht aus den von dir genannten Gründen. Scheinbar wird überprüft ob die jeweilige XML-Datei vorhanden ist und auch gültig ist. Dies kostet wohl recht viel Zeit und verursacht diese lange Wartezeit.


    Das nutzen vieler XML-Dateien bringt meiner Meinung nach mehr Übersicht. Damit ist es auch nicht widersprüchlich zu dem Scene-Konzept. Aber es ist wohl sinnvoller diese ausgelagerten "Codeschnipsel" über eine andere Funktion einzubinden? Fragt sich nur grade welche...

  • ...Das ganze ist aber trotzdem recht blöd, da man so gezwungen ist, die ganze sache in einer XML-Datei zu speichern. Jeder Versuch die Übersicht zu waren, indem man die einzelnen Panos in eigene XML-Dateien auslagert wird dadurch zu tote verurteilt...

    Sorry vielmals, aber da schießt Du Dir selbst ins Knie.

    'loadpano' ist dafür da, einzelne Panoramen in einzelnen xml aufzurufen. Also genau und exakt dafür, was Du machen möchtest.

    'loadscene' ist dafür da, mehrere Panoramen in eine einzige xml schreiben zu können. Das möchtest Du aber doch gar nicht.

    Beides funktioniert hervorragend.

    Wenn Du Dich nun darüber beschwerst, daß 'loadscene' mit einzelnen xml nicht gut klarkommt, dann ist das vollkommen absurd, denn dafür ist ja loadscene gar nicht gedacht.

    Lamborghini ist z.B. mal ne Traktorenfirma gewesen (eigentlich immer noch...), aber keiner kauft sich den Sportwagen und beschwert sich dann darüber, daß man ja seinen Pflug auf dem Feld mit dem schönen neuen Countach überhaupt nicht vernünftig gezogen bekommt... *g*

    ... das ist schade. Ich hoffe, dass dieses Problem bei einem der nächsten Releases verbessert wird. (wenns denn geht)


    Es ist kein Problem (s.o.) und deswegen besteht auch kein Grund etwas zu verbessern.

    Theo

  • scheinbar hab ich dann wohl ein anderes Verständnis von include url bzw. verwechsel das mit einem anderen include. Nach meinen Verständnis sollte diese Include-Funktion nur dazu führen, dass der XML-Parser an dieser Stelle dann die angegebenen XML-Datei kopiert und einfügt, also prinzipiell am Ende aus dem Parser das selbe herauskommt wie bei manuell eingefügter XML-Datei. Es also nur der Übersichtlichkeit dient. Du scheinst aber eher dem include url die selbe funktion wie dem loadpano(abc.xml,...) zuzusprechen. dem dürfte aber nicht so sein.


    aber am ende stimmt es zumindest, das die performance gleich ist, wenn ich die loadscene-variante nutze mit den reinkopierten einzel-xml-dateiinhalt oder die loadpano variante mit dem laden der jeweiligen xml-Dateien.


    Was du aber immernoch nicht verstehst, das man aufgrund der übersichtlichkeit, wenn man viele panoramen über scenes verbinden will, halt gerne einzelne Parts doch mal ausgliedern will (auch wenn das mit der loadpano variante ebenfalls geht).


    Was aber an dieser Stelle deutlich geworden ist, die include-Url-Funktion verursacht ein arges Performanceproblem und dadurch ist allgemein eine Aufspaltung einer XML-Datei in eine Haupt- und mehrere Unter-XML-Daten mit einen Performanceverlust einhergehend.


    (man möge das mal abstrahieren auf ein Panorama mit extrem vielen Hotspots, Actions etc. Das Ausgliedern der Actions, Hotspots etc in eigene XML-Dateien zur besseren Übersichtlichkeit und der besseren Handhabbarkeit ist damit also immer mit einem Performanceverlust verbunden)


    Aber wie gesagt, mittlerweile hat sich das Problem ja erledigt. Der Titel des Themas ist mittlerweile überholt. Loadscene ist nicht langsamer, sondern nur die Nutzung der include-url-Funktion ist problematisch.

  • Also, über include habe ich eigentlich gar nicht gesprochen, aber das nur am Rande...

    Ich habe jedenfalls noch keine Performanceprobleme feststellen können, wobei ich mich auf eine eigene "Panoramatour" beziehe, die z.Zt. aus 150-200 Panoramen besteht.
    Ich habe den ganzen Kram ebenfalls aus Gründen der Übersichtlichkeit in viele xml-Dateien aufgesplittet, die jeweils selbst wiederum aus bis zu 20 Scenen bestehen.
    Ist alles definitiv kein Problem (nicht nur lokal, sondern auch online).
    Der 'include-Befehl' steht jedoch niemals innerhalb einer Scene, sondern naturgemäß immer in der übergeordneten xml-Datei.
    Anders würde bei mir auch der Scene-Aufruf nicht funktionieren, da selbige in der zu inkludierenden Datei steht. Ich muß sie also vorher erstmal laden, bevor ich die Scene aufrufe, logisch...

    Wie auch immer...

    Gruß, Theo

  • Hi,

    zuerst hier ein paar Hintergründe warum das <include> den Start verlangsamen kann:

    1. zuerst wird die erste XML geladen
    2. dann wird das XML auf <include> Tags untersucht
    3. wird ein <include> gefunden, wird diese zu inkludierende XML geladen
    4. ist das Laden fertig, wird der XML Code dieser Datei anstelle des <include> Tags in den XML Code eingefügt (ein eventuell vorhandener <krpano> Root-Knoten wird dabei entfernt)
    5. dann beginnt der Prozess von vorne (Punkt 2)
    6. erst wenn alle <include> Tags aufgelöst sind, beginnt der Panorama laden selbst


    d.h. es wird immer nur eine XML geladen und erst wenn die eine fertig ist erst die nächste, bei sehr vielen <include> Tags kann dadurch das Starten des Panos (hier gibt es aber Verbesserungspotential, siehe weiter unten Optimierungen),


    dazu ein paar weitere Hintergrunde (welche von krpano aber nicht beeinflusst werden können):

    • das Laden vieler kleiner Dateien ist langsamer als das Laden weniger großer Dateien!
    • das Aufbauen und Abbauen einer Serververbindung benötigt im Fall kleiner Dateien meist mehr Zeit als der Download selbst
    • je nach Browser kann nur eine beschränkte Anzahl gleichzeitiger Server/Download-Verbindungen hergestellt werden (zur Zeit meist 6 Verbindungen/Server)


    Optimierungen:

    für die nächste krpano Version habe ich das XML <include> Laden etwas geändert:
    es werden dann gleich auf einmal (falls vorhanden) die nächsten 6 XML Include Dateien vom Server angefordert und zwischengespeichert, d.h. es werden bis zu 6 XML Dateien gleichzeitig geladen,

    hier eine vorläufige Testversion mit diesen Optimierungen - krpano10812test.zip
    (bitte um Feedback!)

    das sollte das Laden und den Start etwas beschleunigen, die prinzipiellen Nachteile vieler kleiner Dateien (siehe weitere Hintergrunde), können damit aber weiterhin nicht umgangen werden,

    eine weitere Art der Optimierung wäre es alle XML Dateien per kprotect Tool mit einzubinden, dann wird nur eine einzelne Datei (die .swf) geladen, wodurch die vielen Serverbindungen wegfallen, und der Start des Panoramas deutlich früher beginnen sollte,

    Schöne Grüße,
    Klaus

  • diese art und weise erklärt natürlich das langsame verhalten. ich hab dir mal ne PM mit der sache geschickt. einmal mit alter krpano.swf und einmal mit neuer krpano.swf


    Jedoch konnte ich keinen spürbaren unterschied feststellen. anhand der beiden links in der pm kannst du das ja selber ausprobieren. (sorry das ich die links hier nicht öffentlich poste, aber da das ganze noch kundenspezifische Panos enthält, deren Freigabe ich noch nich bekommen habe gehts erstmal nur so)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!