Update-Performance

[frankenChris]

Hi zusammen,

mir ist aufgefallen, dass meine CV über die Jahre mit zunehmendem Inhalt im "Update-Fall", damit meine ich die Zeit bis z.B. der geänderte Status eines Lichts angezeigt wird, immer langsamer wurde (Das kann schon mal 1-2 Sekunden dauern). Ich habe nun testweiße mal einen großteil der Visu abgeklemmt - und schon ist das wieder fix (also ich danke im 100ms-Bereich). Dabei ist die Anzahl der GAs auf der aktuellen Page nicht das entscheidende, sondern wohl die Gesammt-Anzahl aller GA's. Um da nun etwas zu optimieren, wäre es gut zu wissen, ob es z.B. etwas bringt, mehrfach-Verwendungen der gleichen GA's zu entfernen? (ich hab da fast alle Werte mehrfach - je Raum und noch in thematischen Gesamtübersichten...)
Oder wo könnte ich noch ansetzen?

Gruß
Christian

[Chris M.]

Erst mal: welche Version?

Und was meinst Du mit langsamer? Visu->Bus oder Bus->Visu?

[frankenChris]

Inzwischen die 0.10.2... Bus->Visu meine ich, klick ich z.B. auf einen Switch für ein Licht, ist das Licht tatsächlich fix an, der Aktor sendet ein Status-Update. Dann dauerts einige Zeit, bis dieses Status-Update in der Visu sichtbar ist, also z.B. ein anderes Icon angezeigt wird.

[Chris M.]

OK. Auf welchem System bzw. welchem Backend? WireGate? OpenHAB?

[frankenChris]

Wiregate, aktuellstes Update.

[Chris M.]

Eine Mehrfachverwendung von GAs ist zumindest was die Kommunikation angeht unkritisch - egal wie oft eine lesende GA in der Config ankommt, die wird nur 1x an die Abfrage-URL gehängt.

Jetzt könnte zumindest grundsätzlich sein, dass entweder die Config so groß ist, dass einfach so viele Adressen zusammen kommen, dass es langsamer wird - und/oder dass die interne Verteilung in der Visu einfach so lange dauert.
Bei beidem kann ich mir spontan kein Problemmechanismus dafür vorstellen.

Um nun der Sache etwas tiefer auf die Spur zu kommen:
Kannst Du mal bei der großen Config im Browser die Konsole (Strg+Shift+I) öffnen, dort auf die Netzwerk-Sicht gehen und mal aufpassen, was passiert wenn auf dem Bus etwas passiert, z.B. wenn Du einen Taster drückst.
=> Der aktuell offene r-Request sollte beendet werden - wie hoch ist da die Latenz zum Tastendruck?
=> Es sollte gleich einen neuen r-Request gegen - wie hoch ist da die Latenz zum Tastendruck und zum Schließen des alten r-Requests?
=> Der Statuswechsel sollte in der Visu angezeigt werden - wie hoch ist da die Latenz zum Tastendruck?

Normalerweise müsste man hier Code einbauen um die Zeiten zu stoppen, da das zu schnell ist um beobachtet zu werden. Aber wenn Du von einer gefühlten Sekunde sprichts sollte zumindest eine qualitative Aussage möglich sein

[frankenChris]

Hi, ich habe das ausprobiert. Allerdings ändert sich da so viel selbstständig, dass ich kaum die Reaktion auf meinen Klick heraus filtern kann. Und Firefox ist auch noch recht träge dabei. Ich probier mal Chrome aus...

[Chris M.]

Nach dem öffnen erst mal bisschen Stabilisieren lassen. Mit dem Öffnen selbst werden natürlich viele Verbindungen geöffnet und geschlossen, die interessieren hier aber erst mal nicht.

Ansonsten: Nutzt Du rsslog? Falls ja: wie viele Einträge hast Du in der Datenbank?

[frankenChris]

Chrome ist schon besser, da auch mit dem Network-Monitor performanter. Trotzdem fast unmöglich, da was rauszuerkennen - ich habe teils mehrmals pro Sekunde neue Connections. Ist recht viel los bei mir auf dem Bus... Wenn ich so einen Request anschaue, sehe ich dass der über 4000 Zeichen lang ist, bei 9/10 Zeichen pro GA sinds also > 400 GAs die meine Visu verarbeitet... Ist das schon sehr viel?
Wäre es eigentlich denkbar, nur die auf der aktuellen Page verwendeten GAs "abzufragen"?

[Chris M.]

Es gibt da mehrere Optimierungsmöglichkeiten - wie nur die GAs der aktuellen Seite abfragen, nie sich ja eigentlich nicht ändernde Liste der GAs nicht jedes mal zu übertragen (-> "filter", vgl. Protokoll Definition) und wahrscheinlich noch mehr.
Das ist alles nicht umgesetzt, da es bisher kein Problem dargestellt hat.

Ob Du nun der erste bist, der hier eine kritische Größe überschritten hat und/oder einfach eine so große Bus-Last hast, dass das zum Nadelöhr wird kann ich nicht beurteilen - wäre möglich aber muss nicht zwingend auch wahrscheinlich.

Die Kommunikation ist im Übrigen so aufgebaut, dass auch bei einer so hohen Last keine Informationen verloren gehen.
Solltest Du nun annähernd alle GAs in der Visu haben dann kannst Du in dem Netzwerk-Monitor auf die Zahl hinter dem "i=" in der Aufruf-URL schauen. Wenn diese Zahl nur einfach hochzählt, dann kommt auch jedes Paket einzeln. Wenn der Wert immer um mehrere Zahlen hochspringt, dann *kann* es sein, dass die Kommunikation nicht mehr hinerher kommt. Dann solltest Du in die Antworten des Servers schauen. Wenn dort immer mehrere GAs beantwortet werden, dann ist die Kommunikation überlastet. Wenn da meistens nur eine GA beantwortet wird, dann ist die Kommunikation ausreichend (das wäre dann der Fall, wenn auf dem Bus deutlich mehr los ist als GAs in der Visu angezeigt werden).

An sich sollte bei einem KNX auf TP (also klassisch auf der grünen Leitung) die Kommunikationsschnittstelle nicht wirklich überlastet werden können - dazu hat ein 100 MBit Netzwerk einfach eine viel zu große Bandbreite gegenüber den 9,6 kBit des KNX... (Bei beliebig langsamer werdender Mobilfunk-Verbindung wird das jedoch nicht mehr beliebig gelten)

[frankenChris]

Mein Wiregate hatte leider einen CF-Defekt, ist jetzt wieder einsatzbereit. Ich habe es nun auch etwas entlasted, indem ich die Multiroom-Funktionalität (MPD) auf einen Raspi ausgelagert habe. Dementsprechend ist auch die CV-Performance gefühlt besser geworden. Ich beobachte das mal und forsche bei Bedarf weiter nach...