Verhalten von Colspan am IPhone und Ladeverhalten (0.9.2 und rev2742)

[Chris M.]

Das Verhalten ist auch in der RC4 das gleiche.

War zu erwarten - aber schon mal schön, dass es konstant ist.

Kann mich hier leider nur wiederholen: meine alte Version lädt zwar generell viel langsamer (15sec), dafür aber immer im 1. Anlauf erfolgreich. Auch in dieser Version kommen zuerst die Bilder, dann die rsslogs und zuletzt die KNX Stati.

Das Laden der Visu-Seiten an sich haben wir ja mit der 0.10 beschleunigt, aber der Client müsste schon zur 0.9.2 geändert worden sein und seit dem gleich geblieben sein.
Auf der Server-Seite hat sich auf dem Wiregate meines Wissens nach nichts geändert. (Beim knxd gab es in der Zwischenzeit neue Versionen, insb. auch beim eibread-cgi.c, was ja hier verwendet wird)
=> Wenn die Theorie stimmt, dass es ein Thema am Backend ist, so kann dies maximal dadurch beeinflusst worden sein, dass der Client nun eher weniger Last erzeugt?!?
Oder doch mehr Last erzeugt, da die einfachen, statischen Web-Seiten nicht mehr in's Gewicht fallen und statt dessen der Abruf der dynamischen geballt kommt?

In der aktuellen git und RC4: Wenn's klapp sind die Stati nach 2sec da und der Rest nach 3sec, aber leider eben nur bei jedem 7-10 Reload oder eben nach 3-4min Warten.

Ich kann bei meinem Wiregate (live genutzt mit durchaus einigen WG-Plugins - die aber alle mit bewusst kurzer Laufzeit um die Latenz bei KNX-Paketen kurz zu halten) auch mit vielfachem Reload mit der Git-Version das Problem leider immer noch nicht nachstellen. Sowohl mit aktivierten als auch mit deaktiviertem Browser Cache. Immer mit der Demo-Config getestet.

Hab hier mal die files aus /lib angehängt.
Hier hat sich offensichtlich vieles getan, seit meiner letzten funktionieren Version und aktuell:
cometcisu-client.js => meine alte Version => OK
CometVisuClient.js => aktuelle RC4 => NOK

Diese Änderung sollte aber bereits zwischen 0.9.1 und 0.9.2 passiert sein.

Wie kann ich hier helfen?

Um hier wirklich klar festlegen zu können ob es auf dem Client oder auf dem Server passiert wäre ein Wireshark Log der r-Requests spannend.

Von meiner Seite nichts Neues. Da ich kein Programmierer bin, benötige ich zumindest ein paar Anhaltspunkte, um ein Debugging durchführen zu können. Ich bleibe bis auf weiteres bei der alten CV Version und werde über kurz oder lang zu einer anderen Visu wechseln (das Problem habe ich vor über einem Jahr gemeldet und mehrfach um Hilfe gebeten, aber da das Problem wohl nur uns beide betrifft, besteht offentlich kein Interesse an einem Lösungsansatz). Schade eigentlich.

Ich will ja helfen - nur ohne Ansatzpunkt kann ich halt nicht

Sobald ich das Problem bei mir nachstellen kann wären wir schon einen großen Schritt weiter!

[Robert_Mini]

Von meiner Seite nichts Neues. Da ich kein Programmierer bin, benötige ich zumindest ein paar Anhaltspunkte, um ein Debugging durchführen zu können. Ich bleibe bis auf weiteres bei der alten CV Version und werde über kurz oder lang zu einer anderen Visu wechseln (das Problem habe ich vor über einem Jahr gemeldet und mehrfach um Hilfe gebeten, aber da das Problem wohl nur uns beide betrifft, besteht offentlich kein Interesse an einem Lösungsansatz). Schade eigentlich.

Das wäre sehr Schade! Bitte nicht aufgeben. Ich denke, das hier sehrwohl Interesse besteht, das Problem aber schwer reproduzierbar und debugbar ist.

=> Wenn die Theorie stimmt, dass es ein Thema am Backend ist, so kann dies maximal dadurch beeinflusst worden sein, dass der Client nun eher weniger Last erzeugt?!?
Oder doch mehr Last erzeugt, da die einfachen, statischen Web-Seiten nicht mehr in's Gewicht fallen und statt dessen der Abruf der dynamischen geballt kommt?

Um hier wirklich klar festlegen zu können ob es auf dem Client oder auf dem Server passiert wäre ein Wireshark Log der r-Requests spannend.

Wireshark ist bereits installiert. In welchem Format soll ich den log speichern? => .pcapng ok?
Siehe Anhang.

Ich will ja helfen - nur ohne Ansatzpunkt kann ich halt nicht
Sobald ich das Problem bei mir nachstellen kann wären wir schon einen großen Schritt weiter!

Klingt nach einem Commitment! .
Am besten das Release raus und dann geht es an die Suche!

lg
Robert

[Robert_Mini]

Ich kann bei meinem Wiregate (live genutzt mit durchaus einigen WG-Plugins - die aber alle mit bewusst kurzer Laufzeit um die Latenz bei KNX-Paketen kurz zu halten) auch mit vielfachem Reload mit der Git-Version das Problem leider immer noch nicht nachstellen. Sowohl mit aktivierten als auch mit deaktiviertem Browser Cache. Immer mit der Demo-Config getestet.
Diese Änderung sollte aber bereits zwischen 0.9.1 und 0.9.2 passiert sein.

Hallo Chris!
Bin jetzt selbst überrascht, den ich dachte bisher, dass es auch beim letzten Release schon ein Problem war.
ABER: 0.9.2 geht, nur develop von git und RC1-RC4 geht nicht!

Was auffällt:

1409    3.282287    192.168.1.3    192.168.1.101    HTTP    3538    GET /cgi-bin/r?s=SESSION&a=1/5/0&a=0/0/4&a=10/0/4&a=10/1/0&a=5/3/4&.....

unter 0.9.2 kommt das erste GET mit r?s=SESSION
unter 0.10.0_RC4 mit r?s=undefined

Wo liegt eigentlich das File CometVisuClient.js in der 0.9.2? im /lib wie bei allen anderen Versionen bei mir jedenfalls nicht.

lg
Robert

[Chris M.]

Wireshark ist bereits installiert. In welchem Format soll ich den log speichern? => .pcapng ok?
Siehe Anhang.

Anhang fehlt. Ich bin nicht der Wireshark-Experte - schön wäre es, wenn das bereits so gefiltert ist, dass nur noch der HTTP-Austausch zwischen Server und Browser vorhanden ist. Das sollte die Datei kleiner halten.

Ansonsten wäre "das übliche" Format i.O. - bzw. alles was ich bei meinem öffnen kann.

Hallo Chris!
Bin jetzt selbst überrascht, den ich dachte bisher, dass es auch beim letzten Release schon ein Problem war.
ABER: 0.9.2 geht, nur develop von git und RC1-RC4 geht nicht!

Das ist schon mal interessant. Wenn auch für mich - aktuell nicht plausibel...

Was auffällt:

1409 3.282287 192.168.1.3 192.168.1.101 HTTP 3538 GET /cgi-bin/r?s=SESSION&a=1/5/0&a=0/0/4&a=10/0/4&a=10/1/0&a=5/3/4&.....

unter 0.9.2kommt das erste GET mit r?s=SESSION
unter 0.10.0_RC4 mit r?s=undefined

Das mit dem "s=undefined" ist mir auch schon aufgefallen (ist bei mir genau so). Da wir aber aktuell das Session-Handling nicht nutzen habe ich dem erst mal keine Prio gewidmet.

Wo liegt eigentlich das File CometVisuClient.js in der 0.9.2? im /lib wie bei allen anderen Versionen bei mir jedenfalls nicht.

Im Release gibt's die Datei einzeln nicht mehr, die wird minimiert und geht in der großen JavaScript-Datei auf.
Im Source, also z.B. dem Git der 0.9.2 (-> https://github.com/CometVisu/CometVi.../release-0.9.2 ) gibt es die schon noch, heißt nur leicht anders: https://github.com/CometVisu/CometVi...visu-client.js

[Robert_Mini]

Hallo Chris!

Nachdem das Release nun draußen ist, kann's ja weitergehen!
Release 0.10.0 ist installiert.

Unter diesem Link:
https://www.dropbox.com/sh/lldzqubmu...8BOy0zcLa?dl=0

habe ich folgendes abgelegt:
- config_large_editor.xml
- meine custum/mobile.css
- meine rrds
- Wireshark files

Die Wireshark File sind gefiltert nur mit 192.168.1.3 (=mein WindowsPC mit der CV in Firefox51.0.1) und 192.168.1.101 (=mein WG).
- Load_CV0.9.2_per_URL_afterCacheClearing_47s.pcapng => nach vollständig Cache löschen, nach 47sec kommen die KNX Stati
- Load_CV0.9.2_per_URL_14s.pcapng => 2. Ladevorgang, nach 14sec kommen die KNX Stati, das funktioniert reproduzierbar gut!

- Load_CV0.10.0_per_URL_afterCacheClearing_64s.pcapn g => nach vollständig Cache löschen, nach 64sec kommen die KNX Stati => nicht immer aber meistens greift nach vollständigem Cache leeren der 1. Watchdog nach 60sec!
- Load_CV0.10.0_per_URL_250s.pcapng => 2. Ladevorgang nach Reload, nach 250sec kommen die KNX Stati , das ist leider der Regelfall, mal 180s, mal 250s, mal >300s.

Einer der seltenen Glückstreffer:
- Load_CV0.10.0_per_URL_afterCacheClearing_30s.pcapn g => nach vollständig Cache löschen, nach 30sec kommen die KNX Stati, schneller als bei der 0.9.2.
- Load_CV0.10.0_per_URL_1s.pcapng => Reload, absoluter Rekord, Visu und Stati sind unter 2s da, rsslog kommt nach ca. 10s.

Man sieht, wenn's passt funktioniert das Laden pfeilschnell, leider ist das im Moment bei mir leider die Ausnahme! Daher bin ich absolut motiviert, das Problem zu lösen, brauche aber deine tatkräftige Unterstützung.

Danke und lg
Robert

PS: @XueSheng: ist dein Verhalten in der 0.9.2 auch ok wie bei mir?

[peuter]

Also, keine Ahnung ob es überhaupt was mit Deinem Problem zu tun hat, aber die config_large_editor.xml ist nicht valide:

• Das enable_column_adjustment Attribut im pages-Element gibt es nicht mehr
• im Meta-Element stehen zwei Attribute (name, content) die ich noch nie gesehen habe, und laut Schema sind die da auch nicht erlaubt
• Dann gibt es noch etliche address-Elemente mit readonly-Attribute, was es auch nicht mehr gibt (durch mode ersetzt)

Ich bezweifle zwar das es das Problem löst, aber trotzdem solltest Du die Config erstmal reparieren.

[Robert_Mini]

Hab grad die Config aktualisiert und wieder hinaufgeladen.
Leider stimmt deine Erwartung - das Problem besteht weiterhin.

Robert

[Chris M.]

Ich hab mich jetzt erst mal nur auf den 250s Dump gestürzt. Mit meinen rudimentären Wireshark-Kenntnissen (und natürlich bisschen https://lmgtfy.com/) kam ich auf diesen hübschen Screenshot:
Screenshot_20170307_214946.png

Was sagt uns das?

• 4x wird ein r gesendet, t=0, keine Antwort kommt, Abstand immer 60 Sekunden
• Der fünfte r mit t=0 bekommt sofort eine Antwort, danach flutschen die r so wie sie sollen
• Zwischen drinnen kommt ein Doppelpack rsslog, mit einem Intervall von 30 Sekunden

Ein Blick in den Code zeigt noch, dass beim normalen Backend der CometVisuClient ein Timeout von 60 Sekunden hat, was in einem Neustart der Verbindung resultiert (überprüft vom Watchdog in 5 Sekunden-Intervallen).

Interpretation:

• Beim Visu-Stat hat im problematischen Fall das WireGate nicht ausreichend Ressourcen frei um innerhalb von 60 Sekunden auf den initialen r zu antworten

Lösungsszenarien:

• Die Ausführung des r auf dem WireGate beschleunigen
  • r direkt beschleunigen - sehe ich als nicht sinnvoll machbar, würde außerdem vermutlich root-Zugriff benötigen und wäre somit nicht in der Breite machbar
  • die Last auf dem WireGate reduzieren
    • rsslog-Aufrufe reduzieren? Z.B. refresh dort hochsetzen?
    • andere Last reduzieren
      • drraw-Graphen?
      • WireGate-Plugins?
      • anderes?
• Den Timeout hoch setzen
  • Brauch Zugriff auf die Sourcen - in der Git-Version leicht machbar (Zeile 56), im (aktuellen... ) Release quasi nicht machbar

Schau mal ob hier was machbares dabei ist und ob das eine Verbesserung bringt. Das würde schon mal die Theorie bestätigen

[Chris M.]

Nachtrag:
Der Client hat sich tatsächlich zwischen 0.9.2 und 0.10.0 geändert, da war mein letzter Blick in den Code nicht richtig.
Zur 0.10.0 kam der vereinheitlichte Client, der das traditionelle Backend mit dem OpenHAB Backend zusammengeführt hat.

=> Hier besteht grundsätzlich das Risiko, dass sich beide Versionen nicht gleich verhalten

Der WireShark-Dump zeigt mir jedoch, dass hier ein Reset vom Client aus passiert sein muss (evtl. kann hier jemand mit besseren WireShark-Kenntnissen das bestätigen) - was durchaus dem gewünschten Verhalten entsprechen würde.
D.h. wenn die Annahme stimmt, dass sich der Client bei der 0.9.2 und 0.10.0 gleich verhält (weil wir keinen Bug eingebaut haben) dann sollte auch die 0.9.2 sich gleich verhalten und das gleiche Problem zeigen - wenn auch hier vom WireGate nicht innerhalb von 60 Sekunden eine Antwort kommt.

Da die 0.9.2 jedoch eine andere Last auf dem WireGate erzeugt (ich hätte vermutet(!): einen höhere...) kann es gut daran liegen, dass es daran liegt, dass das Thema dort nicht auffällt.

Oder der Client der 0.9.2 hat sich doch anders verhalten als der der 0.10.0...

[Robert_Mini]

Hallo Chris!
Super, dass du dich um das Thema annimmst :-)
Ehrlich gesagt, glaub ich nicht an ein Performance Problem am WG. Im Anhang eine Übersicht. Es laufen zwar einige Plugins, aber alle mit Zyklen um 60-300s bzw. nur bei events, alle compiliert. Es läuft bei mir auch keine Visu ständig, nur on demand am Tablet, PC oder Handy und wird dann wieder geschlossen.

Auch bei einer kleineren Visu ohne rsslog habe ich das gleiche Problem. Und dass das WG 60s keine Zeit zum Antworten hat, never ever. Mir scheint eher, dass die Anfrage "ignoriert wird/verloren geht" und deshalb nach 60s ein erneuter Versuch folgt.
Kleiner Beweis dafür: Wenn die Stati nicht "sofort" da sind, drücke ich F5, nach 5s wieder, etc. Nach dem 4-6 Versuch sind die Stati da wieder "sofort" da. Und ich habe beim Reload nicht das Gefühl, das die CV aufgrund "Überlast" länger laden täte.

Weiters habe ich gerade parallel eine Console am WG geöffnet. Die CPU last die ich mit "top" sehe, geht beim Reload für 2sec auf cpu 0%id und dann wieder zurück auf 70-75% idling.

Noch ein paar Ideen:
- Kann ich eigentlich testweise den client von 0.9.2 unter 0.10.0 testen?
- Auch könnte ich StefanW bitten, mir einen WG zum testen zur verfügung zu stellen, dann ohne Plugins, rrds und Sensoren...

Danke und lg
Robert

[XueSheng]

Den Aufwand mit zweitem WG zum Testen wollte ich nicht betreiben, daher habe ich eine WG Instanz für Testzwecke virtualisiert (Server mit Xeon E3, usw). Der Zugriff auf den Bus erfolgt jedoch nicht autark, sondern übers Netzwerk (eibd auf Wiregate).

Folgendes habe ich festgestellt:
WG (original):

• Deaktivieren aller Plugins (rsslog, diagram und colorchooser) ändert nichts am Problem
• starke Reduzierung der GAs verbessert die Situation deutlich (je weiter die Visu abgespeckt wird, desto seltener tritt das Problem auf)

WG (virtualisiert):

• Problem lässt sich deutlich seltener hervorrufen.
• Wenn eine Antwort auf t=0 ausbleibt, fängt sich die Visu i.d.R. innerhalb weniger Minuten. Bei WG (original) kann das schon mal ins Unendliche gehen (nach 1h noch keine Buswerte und noch immer Anfragen mit t=0).

Mir ist nicht klar wo sich der Client der Visu versteckt (irgendwo im JS Code?). Der Ansatz von Robert könnte durchaus interessant sein (Austausch Client 0.9.2 und 0.10.0)

[peuter]

Benutzt eventuell jemand von Euch dieses Feature: http://cometvisu.org/CometVisu/de/la...blequeue-queue
Hab gerade festgestellt, dass diese Funktionialität beim Überarbeiten des CometVisu-Clients für 0.10.0 verloren gegangen ist. Das würde zumindest unterschiedliche Verhaltensweisen zwischen den Versionen erklären, aber nur wenn mans auch benutzt. Ohne den URL-Parameter ist das sowieso abgeschaltet, weil noch experimentell und hat vielleicht sowieso nie richtig funktioniert.

[peuter]

Hab mir die Frage selbst beantwortet: Kann nicht sein, dass das jemand benutzt, den man bekommt direkt ne Fehlermeldung auf der Console und niemals irgendwelche Stati in dem Fall.

[Chris M.]

So, mal ein Versuch - ist nur temporär und funktioniert nur auf dem WireGate und bei ähnlich aufgesetzten Geräten: Ich habe den Client-Code der 0.9.2 mal so erweitert, dass die 0.10.0 damit funktioniert (funktionieren sollte... Bitte auf der Konsole auf Fehlermeldungen achten! Ist ja nur ein Hack...).

=> Bitte mal bei der Git-Version (nicht dem minimized Release!) die /src/lib/CometVisuClient.js durch die angehängte (entpackte!) Datei ersetzen und dann nochmal testen.

Tritt das Problem nicht mehr auf, suchen wir im Client weiter. Tritt das Problem weiterhin auf, dann ist's eher ein Problem am Server.

[Robert_Mini]

Hallo Chris!

Vorweg - Danke für dein Engagement!!!
Leider habe ich keine gute Nachricht: Habe die Client-Datei in die aktuelle git kopiert, das Problem besteht leider weiterhin.
Hab nochmal ein paar Wireshark files auf den dropbox link geladen => Dateinbezichnung: Load_CV_git_special_per_URL_....
https://www.dropbox.com/sh/u9jcvfrj4...W5MfBJH3a?dl=0

Was hat sich sonst bei 0.9.2 => 0.10.0 geändert? Die 0.9.2 lädt absolut zuverlässig und schnell (ca. 5s).
Wurde serverseitig was geändert? Wo sind eigentlich die Files des backends, wo die GET... abgearbeitet werden oder ist das schon im eibd? Sorry, habe die Details der Kommunikation der CV leider immer noch nicht durchschaut.

Danke
Robert