erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[herrmannj]

bekommste aber nicht  weil:

Dann müsste sv ja jeden wert explizit quittieren. Läuft aber so das die in einem puffer landen und dann eben vom tcp Stack abgeliefert werden.

vg
jörg

[HCS]

... Läuft aber so das die in einem puffer landen und dann eben vom tcp Stack abgeliefert werden.

Und wenn es in den Puffer soll, könnte man doch schauen, ob es schon drin ist und das vorhandene GAD ersetzten, anstatt es nochmal einzufügen?

[HCS]

@herrmannj: Ich habe Deine Strategie aus dem POC in den FHEM-Treiber übernommen. Das von Dir angesprochene Problem mit den arrays ist mir dann auch noch klar geworden, das ist bei widgets wie temprose und comfortchart, die ein array mit Werten benötigen, nicht gegangen. Das habe ich geregelt.

Den timeout habe ich ausgebaut, das geht auch ohne gut.
Den cache der Werte lasse ich in der widget Klasse laufen, der springende Punkt waren ja die delegates.

Die Messungen auf dem Tablet mit der gewohnten Umgebung ergeben:
Monitor incl. splitten der GADs für fronthem und den addon treiber und Aufteilung in "normales GAD", chart und log ca. 80-100ms
Aktualisierung von einem GAD: 1-4ms, überwiegend 1-2ms
Gefühlte Geschwindigkeit: Gut

Das wäre also gemessen knapp an dem POC dran.

Ein Problem gibt es noch:
Bei der Aktualisierung von temprose und comfortchart mit call werden zwar die Werte im widget korrekt gesetzt, aber Chrome zeigt das widget nicht korrekt an. Es werden nur teile davon gezeichnet. In FireFox geht das. Darum habe ich vorerst eine Erkennung eingebaut, um (ausschließlich) diese beiden per trigger zu aktualisieren. Muss mal forschen, wie das kommt.

Ich hänge den Treiber zum Testen an. Wer in testet, sollte den Aktuellen vorher sichern, falls er mit diesem mehr Probleme als Freude hat.
Er ist noch experimentell. Bei mir laufen alle meine pages problemlos, aber ich habe auch nicht alle widgets, die es gibt irgendwo drin.

Wäre echt cool, wenn Jörg die richtige Strategie gefunden hätte, dass wir das leidige performance-Thema abhaken und uns cooleren Dingen wie z.B. charts zuwenden können.

Anbei noch ein Schirmschuss von einer meiner test-pages

Nachtrag: ihr müsst mal schauen, wie unheimlich behaglich es bei mir ist (siehe comfortchart) 
Nachtrag2: sorry, das png ist etwas gigantisch groß geworden

[cruser1800]

Ich habe mal den neuen Treiber getestet.

Bevor ich das Temp Verzeichnis gelöscht habe hatte ich noch Fehlermeldungen erhalten. Danach ging es wirklich schnell aber erst beim zweiten Aufruf der einzelnen Seiten. Beim erstenmal war es langsamer als zuvor. Hatte warscheinlich damit zu tun, dass erst die Temp-Dateien angelegt werden mussten.

Aber Seiten mit Grafiken werden zwar schnell aufgebaut, nur die Grafik dauert ewig. Insgesamt war es bei mir mit dem alten Driver und den widges.js von bgewehr schneller.

Weiterhin habe ich bemerkt, dass die Seiten zwar schnell aufgebaut wurden aber danach noch eine weile blockieren. Ein schnelles hin und her schalten zwischen den Seiten ist nicht möglich.

Das alte Verhalten, etwas langsamere Lieferung der Daten, hatte mir besser gefallen, da ich auch die Seiten schneller wechseln konnte. Ist aber alles subjektiv ohne Messung.

Bitte weiter machen, eure Arbeit finde ich toll!!!!

[karl0123]

Das kann ich bestätigen. ich will die Mühe nicht schmälern und würdige sie auch, aber der alte "Treiber" ist in Kombination mit den tiefen delegates deutlich schneller, als der neue. Außerdem blockiert er weniger. Der Seitenwechsel ist mitunter mit dem neuen Treiber wieder merklich nerviger. Ich habe keine Messungen aber ich habe beide Treiber mit identischen Seiten direkt nebeneinander getestet.

Ich habe jedoch auch kein Problem, die widgets zu ändern. Das haben andere vielleicht. Kann man eine "Wahl" zwischen den beiden Varianten einbauen?

Danke!!

[herrmannj]

hmm, komisch. Was denn für "Grafiken" eigentlich.

Ansonsten: wir haben hier schon Luxusprobleme, die Auswahl zwischen zwei turbo drivern.

Ich habe gestern mal im knx forum gestöbert. Die ganzen Themen mit speed und dem re-connect sind da schon thematisiert, dort wurde das nur nie gelöst. Macht wirklich Spaß hier, den progress hier zu sehen und so. Das nur am Rande, muss man auch mal aussprechen

Danke für Unterstützung in die Runde 
Jörg

Ich denk mich mal an die plots ran

[herrmannj]

@karl:

oh - überschnitten. Wegen auswählen: sehe ich kein Problem. Du kannst ja den driver auswählen (in den sv optionen).

Ich würde aber versuchen das wegen dem Umbau an den widgets zu vermeiden.

Die Messungen sind da eigentlich recht eindeutig und die von HCS und meine sind auch konsistent. Das hat also vmtl noch andere (individuelle) Ursachen. Wenn Du möchtest dann geh dem doch nochmal auf den Grund, bspw mit einer jungfräulichen Installation (die kannst Du ja recht easy parallel auf dem Server aufsetzen, per git clone)

vg
jörg

[karl0123]

Die Frage ist, habt ihr (du und HCS) auch mal den alten Treiber in Kombination mit der alternativen widget.js getestet/gemessen? Das ist nämlich wirklich rasant schnell und blockiert nicht.

Getestet habe ich übrigens auf einer sauberen Installation. Individuelle Ursachen würde ich fast ausschließen. Und ja, der neue Treiber ist deutlich schneller als der "alte" Treiber mit der ursprünglichen widget.js. Von daher ist das gut, kommt aber nicht an die genannte Alternative ran.

Ansonsten ist dein Hinweis mit der Auswahl zwar korrekt, ich gehe aber mal davon aus, dass mögliche Neuerungen nur in den "neuen" Treiber kommen. Wobei das auch nicht unbedingt ein Problem für mich sein muss. Dann muss ich sie eben selber "mergen".

Wie gesagt: Top Arbeit hier und ich will nicht kritisieren. Meine Hinweise sollen nur helfen.

[HCS]

Versuch doch mal den Neuen wie er ist mit der alternativen widget, ob das geht.

Das blockieren könnte ich noch lindern. Ich hatte ja die timeouts rausgenommen, in der von Jörg bestärkten Hoffnung, dass der Treiber schneller als fronthem ist.

Vielleicht liefert bei karl das fronthem so irre schnell, dass der Treiber wieder am Anschlag ist. Im Prinzip ist es so, dass je langsamer fronthem liefert desto weniger es blockt.

Ich schlage vor, dass ich mal den timeout wieder einbaue und wir dann schauen, was passiert.

[herrmannj]

ja. Danach ist der POC (deutlich) schneller.

Ist er auch von der Logik: auch wenn der delegate "tiefer" liegt muss das event verarbeitet, sprich durchgereicht/getestet usw werden. Die Strecke ist halt kürzer vom widgetcode bis zum handler code - aber sie ist da.

Beim poc ist genau diese Strecke weg, das GAD kommt rein und wird direkt an den Handler gegeben. Die ø1,5ms gehen für  das reine "neuzeichnen" drauf.

Ansonsten ist dein Hinweis mit der Auswahl zwar korrekt, ich gehe aber mal davon aus, dass mögliche Neuerungen nur in den "neuen" Treiber kommen. Wobei das auch nicht unbedingt ein Problem für mich sein muss. Dann muss ich sie eben selber "mergen".

Ja, das wären Nebeneffekte von zwei driver udn Du musst auch die widget.js immer daran anpassen, deswegen meine Empfehlung da nochmal auf Ursachensuche zu gehen ...

und ich will nicht kritisieren. Meine Hinweise sollen nur helfen.

Na, alles gut. Der Hinweis wenn was anders funktioniert als es soll ist ja absolut gerechtfertigt.

@HCS
hast Du eine Idee wie man vielleicht eine Mess- und Diagnose Seite erstellen kann ? Dann hätte man zukünftig die "Messmethode" standartisiert ... Ist, glaub ich, aber schwer. Weil müsste ja schon im driver ansetzen ...

vg
jörg

[marvin78]

Ich bekomme folgenden Fehler bei Verwendung des neuen Treibers:

Code Auswählen Erweitern

Uncaught TypeError: Cannot read property 'handler' of undefined

Ich kann dann nach einem manuellen F5 noch eine Seite weiter navigieren (Ajax), auf dieser werden dann schon nur noch die Hälfte der gads aktualisiert. Danach funktioniert die Navigation nicht mehr. Ich nutze den SmartVisu Cache nicht.

Eine Idee voran das liegen kann?

[herrmannj]

Versuch doch mal den Neuen wie er ist mit der alternativen widget, ob das geht.

Das blockieren könnte ich noch lindern. Ich hatte ja die timeouts rausgenommen, in der von Jörg bestärkten Hoffnung, dass der Treiber schneller als fronthem ist.

Vielleicht liefert bei karl das fronthem so irre schnell, dass der Treiber wieder am Anschlag ist. Im Prinzip ist es so, dass je langsamer fronthem liefert desto weniger es blockt.

Ich schlage vor, dass ich mal den timeout wieder einbaue und wir dann schauen, was passiert.

ne, die modifizierten widgets gehen nicht weil die delegates in $(document) gesucht werden und da liegen sie nicht. Das umzustellen macht auch keinen Sinn weil der call ja, unabhängig davon wo der delegate mal lag, sowieso direkt ist.

Den timeout würde ich nicht einbauen (sehr dagegen). Die GADs können nicht viel schneller kommen (Bandbreite etc). Und wenn sie es doch würden, geh mal im Schnitt von 2ms aus (bei mir sind es 1.5) dann hast Du 1000GAD in 2Sekunden abgearbeitet. 1000 ...

Der timeout hat ja den drawback das er eine penalty auf alle GAD addiert - also in 99% (100?) der Fälle genau das Gegenteil bewirkt.

Ohne die Ursache zu des Verhaltens (bei karl) zu kennen würde da einen weiten Bogen drum machen ...

vg
jörg

[herrmannj]

Ich bekomme folgenden Fehler bei Verwendung des neuen Treibers:

Code Auswählen Erweitern

Uncaught TypeError: Cannot read property 'handler' of undefined

Ich kann dann nach einem manuellen F5 noch eine Seite weiter navigieren (Ajax), auf dieser werden dann schon nur noch die Hälfte der gads aktualisiert. Danach funktioniert die Navigation nicht mehr. Ich nutze den SmartVisu Cache nicht.

Eine Idee voran das liegen kann?

Hast Du evtl die widgets.js mit den "tiefer gelegten" (sic) Handlern ?

vg
jörg

[HCS]

ja. Danach ist der POC (deutlich) schneller.

Ämm - nach was?

@HCS
hast Du eine Idee wie man vielleicht eine Mess- und Diagnose Seite erstellen kann ? Dann hätte man zukünftig die "Messmethode" standartisiert ... Ist, glaub ich, aber schwer. Weil müsste ja schon im driver ansetzen ...

Die ist in diesem Treiber schon eingebaut.
In Zeile 563 legt man fest, nach wie vielen GADs (so viele muss man auf der page dann mindestens drauf haben) die Messung angezeigt wird.
In Zeile 583 den alert scharf machen.
Der alert zeigt dann die Zeiten an. Entscheidend ist die Zeit in den "OK ..." Zeilen.

Ich bekomme folgenden Fehler bei Verwendung des neuen Treibers:

Code Auswählen Erweitern

Uncaught TypeError: Cannot read property 'handler' of undefined

Spontan nicht. Gibt es noch eine Zeilennummer?

[marvin78]

Ja,  1   ist die min Version. Sorry,  aber ich muss zum Flughafen. Ich teste morgen Abend nochmal mit der "normalen" Version.  Danke.