Aufteilung Conf-File für bessere Performance?

[Fry]

Hallo zusammen,
meine visu_config.xml hat nun etwa 800K und natürlich Hunderte KNX-Adressen drin. Das führt dazu, dass der Aufruf der Visu auf einem etwas schwachbrüstigen Samsung Galaxy (kleines Tablet mit 7 Zoll, das ich günstig 5x kaufen konnte und nun als Visu-Endgerät nutzen will) lange zum Laden braucht und "ewig", bis die Werte angezeigt werden.
Kann man dem irgendwie abhelfen, zum Beispiel durch Aufteilen der config-Datei? Wie würde man das prinzipiell anstellen?
Vielen Dank für Tipps,
Fry

[JuMi2006]

Schau mal hier:

https://knx-user-forum.de/cometvisu/...nd-editor.html

Eine endgültige Einigung konnte ich jetzt nicht rauslesen. Sollte aber dennoch ohne Editor funktionieren ?

[Fry]

Beschleunigt das denn auch? d.h. wird das include erst ausgeführt, wenn man die Seite anklickt?

[MrRemy]

Aufteilung Conf-File für bessere Performance?

Das geht doch heute schon. Nutze ich jedenfalls so.
Man kann beliebige config-files anlegen und über URL-Parameter selektieren.

Ich nutze das für verschiedene Visu bei unterschiedlichen Endgeräten - klappt super!

Kannst Dir ja auch eine root-config anlegen die auf die anderen verlinkt.




Gruß
Mark

[Chris M.]

Das Include-Widget macht's langsammer nicht schneller, da nun ja zwei Dateien übertragen werden müssen...

Grundsätzlich könnte man die Config-Datei natürlich auch per Application Cache zwischenspeichern, so wie den ganzen Rest - aber dann dürfte das Thema des bei Änderungen zu agressiven Caches wieder zuschlagen

Was helfen könnte - aber momentan überhaupt nicht vorgesehen ist - wäre per Include tiefe Sub-Seiten auszulagern und die erst bei Zugriff zu laden...

[netzkind]

Was helfen könnte - aber momentan überhaupt nicht vorgesehen ist - wäre per Include tiefe Sub-Seiten auszulagern und die erst bei Zugriff zu laden...

Ich hab das nicht mehr verfolgt, aber gibt es nicht Features die bestimmte Seiten automatisch bei Auftreten eines Telegramms öffnen? Das wäre dann nicht mehr möglich...

Da finde ich die Nutzung unterschiedlicher Configs für unterschiedliche Bereiche fast logischer; eventuell klappt es da ja sogar, gemeinsame Grundeinstellungen (Mappings etc) in ein shared include auszulagern.

Alternativ das mit dem Caching verfolgen: man könnte den Editor eine Versionsnummer in eine eigene Datei ablegen lassen. Diese holt sich die Visualisierung immer ohne caching, und verwendet sie zur Verwaltung des Cachings der eigentlichen Config (bspw. als Get-Parameter zum Cache-busting).

Grüße,
Julian

[Chris M.]

Ich hab das nicht mehr verfolgt, aber gibt es nicht Features die bestimmte Seiten automatisch bei Auftreten eines Telegramms öffnen? Das wäre dann nicht mehr möglich...

Richtig. Wäre halt ein Tod den man sterben muss. Sehe ich nicht als Show Stopper, da mit leicht anderer Seiten-Aufteilung umgehbar.

Da finde ich die Nutzung unterschiedlicher Configs für unterschiedliche Bereiche fast logischer; eventuell klappt es da ja sogar, gemeinsame Grundeinstellungen (Mappings etc) in ein shared include auszulagern.

Grundsätzlich gerne. Für mich aktuell aber zu abstrakt. Freiwillige?

Alternativ das mit dem Caching verfolgen: man könnte den Editor eine Versionsnummer in eine eigene Datei ablegen lassen. Diese holt sich die Visualisierung immer ohne caching, und verwendet sie zur Verwaltung des Cachings der eigentlichen Config (bspw. als Get-Parameter zum Cache-busting).

Gibt's jetzt schon -> cometvisu.appcache im Oberverzeichnis.

Nachteil daran: Mit geänderter Config werden alle statischen Seiten auch neu geladen...
(@Nestrac die hättest Du bei Deinem Commit auch anfassen sollen damit die Änderungen auch ohne forceReload gefunden und somit geladen werden. Einfach Datum oben aktuallisieren reicht.)

Alternativ könnte man sich etwas tiefer mit Local Storage beschäftigen. Wer ist freiwillig?

[wuestenfuchs]

Kannst Dir ja auch eine root-config anlegen die auf die anderen verlinkt.

Mit welchem Widget machst du denn diese "externen" Links? Habe es mit Pagejumps versucht, habe aber vermutlich nicht die richtige Syntax.