fhemweb FW_Read zu langsam

[martinp876]

Hi,

beim Absetzen eines Kommandos aus dem Webinterface beobachte ich aktuell Delays von 800ms. Diese laufen in der Prozedur FW_Read auf.
Das passiert im deviceview bei einem normalen refresh.
Diese Zeit verzögert das Bearbeiten der Commadqueue in HM. der max delay von 250ms kann nicht eingehalten werden - es kommt zum Abbruch.
Einige Kommandos können aus dem web-interface somit nicht mehr ausgeführt werden, da dieses Delay auch noch korreliert das Kommando IMMER an der gleichen Stelle 'trifft'.

Gibt es Optionen oder ist es in der Mache, FHEM_WEB auf ein max execution time von kleiner 100ms zu begrenzen?

Gruss Martin

[betateilchen]

Gibt es Optionen oder ist es in der Mache, FHEM_WEB auf ein max execution time von kleiner 100ms zu begrenzen?

Ich sehe die derzeitige Entwicklung in FHEMWEB derzeit eher in die andere Richtung gehen - durch immer mehr UI-Ballast wird das Frontend immer noch langsamer.

[rudolfkoenig]

beim Absetzen eines Kommandos aus dem Webinterface beobachte ich aktuell Delays von 800ms. Diese laufen in der Prozedur FW_Read auf.

Und im Telnet abgesetze Kommandos laufen mit dieser Messmethode in telnet_Read auf, die per at im at_Exec, usw.

Gibt es Optionen oder ist es in der Mache, FHEM_WEB auf ein max execution time von kleiner 100ms zu begrenzen?

Einem Anfaenger wuerde ich jetzt eine lange Geschichte von threads/forken und die damit verbundenen Probleme erzaehlen, hier spare ich mir das.

durch immer mehr UI-Ballast wird das Frontend immer noch langsamer.

Frueher war eh alles besser.

[martinp876]

Und im Telnet abgesetze Kommandos laufen mit dieser Messmethode in telnet_Read auf, die per at im at_Exec, usw.

mit telnet läuft es wunderbar.
Mittlerweile habe ich einen retry des messageblocks eingebaut - damit kommt immer(zuverlässig) der Fehler wird aber durch einen auto-retry aufgefangen. Unschön aber viele werden es nicht bemerken

Einem Anfaenger wuerde ich jetzt eine lange Geschichte von threads/forken und die damit verbundenen Probleme erzaehlen, hier spare ich mir das.

danke.
Wäre auch mein Vorschlag an den maintainer von FHEMWEB, der sollte es dann einbauen . Ich denke es sollten immer die forken, die einen langläufer starten. Oder wird es hier umgekehrt gesehen? Muss ich die gesamte IO kommunikation forken? Das wird etwas komplexer, wäre wirkliches multi-tasking und ich müsste eine IPC aufsetzen.... Einzeln Forken geht nicht - zu viele Abhängigkeiten.
00_CUL müsste ich dann auch aufmischen... eben alle IOs für HM.

Ich sehe die derzeitige Entwicklung in FHEMWEB derzeit eher in die andere Richtung gehen - durch immer mehr UI-Ballast wird das Frontend immer noch langsamer.

Frueher war eh alles besser.

Ich schließe mich dem Tenor von Udo an. Habe ich schon früher erwähnt - ein Echtzeitsystem muss das Timing beachten - hier in diesem Fall würde ich tasks über 100ms als kritisch empfinden und versuchen auszulagern. Insbesondere wenn sie häufig und in Zentralfunktionen vorkommen. Diesen Fall ordne ich klar hier ein.

Aber es scheint wieder einmal keinen zu interessieren.

Gruss Martin

[justme1968]

ein Echtzeitsystem muss das Timing beachten

ja. natürlich. aber die frage ist was ist das echtzeit system? ganz fhem? das backend? oder auch da wieder nur ein teil?

so lange alle komponenten mehr oder weniger im gleichen prozess laufen gibt es doch keine wirklich möglichkeit ein timing zu garantieren.

das timing und antwortverhalten einer gesamten fhem installation zu optimieren interessiert ganz sicher mehr als einen. siehe norbert und seine protothreads für owx. oder auch die homematic wired komponenten. zumindest für den einstieg ist es sicher deutlich einfacher auf diese art die komponenten die ein bestimmtes timing brauchen vom rest abzuschotten. je nach timing ist das vermutlich für manches der einzig gangbare weg.

wenn man diesen ansatz dann verallgemeinert und wiederverwendbar in fhem integriert wäre das eine lösung die zum einen timing kritisch komponenten entkoppeln kann und zum anderen genau so fronend module vom backend entkoppeln kann.

eine lösung die nur in fhemweb eingebaut wird hilft glaube ich niemandem.

[martinp876]

so lange alle komponenten mehr oder weniger im gleichen prozess laufen gibt es doch keine wirklich möglichkeit ein timing zu garantieren.

kann man so nicht sagen. Zum einen gibt es genügend non-preemptive echtzeitsysteme, die hervorragend laufen. Die verlangen Disziplin.
Zum Anderen kann man die Bummler forken - was auch schon an vielen Stellen gemacht wird.

wenn man diesen ansatz dann verallgemeinert und wiederverwendbar in fhem integriert wäre das eine lösung die zum einen timing kritisch komponenten entkoppeln kann und zum anderen genau so fronend module vom backend entkoppeln kann.

prima. Bisher ist noch keiner wirklich in mehr als "jaja, sollte man" eingestiegen. So lange man nicht multi-threating betreibt (große Bautelle, ist klar) sollte man sich einigen, wie sich Module und Funktionen aktuell verhalten sollen. Ich wiederhole meinen Vorschlag: 100ms-Grenze, dann muss der Entwickler tätig werden.

Und klar - eine Trennung zwischen backend und Frontend ist wünschenswert.
Sollte es darauf hinauslaufen, dass timing-kritische abläufe geforkt werden (forken allein kostet 30ms) muss z.B. der operationale Teil von CUL_HM/HMLAN und CUL zusammengepackt werden... dann wird es nicht mehr so einfach sichtbar....

eine Lösung die nur in fhemweb eingebaut wird hilft glaube ich niemandem.

niemandem würde ich so nicht sagen. Mir schon einmal - und dem User, der das Problem gemeldet hat - und den Anderen, die sich damit quälen.
Ja, eine generelle Lösung ist schöner - aber so lange das keiner in Angriff nimmt muss jeder Verantwortliche dies selbst tun. Das haben schon Einige (incl mir) so gemacht. fhemWeb ist sehr Zentral, betrifft jeden. Das darf man so eigentlich nicht aufsetzen.

Gruss Martin

[rudolfkoenig]

mit telnet läuft es wunderbar.

Das haette ich gerne mit Beispielen/Fakten belegt. Und wenn ich in FHEMWEB etwas aendern soll, dann haette ich gerne das Problem soweit beschrieben, dass ich es nachstellen kann. Ich habe mit FHEMWEB und FHEM kein Problem.

Wenn einer der Subsysteme auf genaues Timing angewiesen ist (wie CUL_HM @ CUL), dann sollte sie dafuer sorgen, dass sie es leisten kann. Wenn die gefundene Loesung von den anderen Modulen verwendet werden kann, umso besser, wenn es gut funktioniert, werde ich es nach Kraeften unterstuetzen.

Ich finde es aber auch ok, bei nicht selbst verschuldeten Sachen das Problem nicht zu loesen. Z.Bsp. wer auf einem FritzBox mit CUL+CUL_HM groessere Plots berechnen will, der hat ein Problem. Der moege entweder kein Fritzbox, kein HM,  kein CUL oder keine Plots haben. Oder sich nicht beschweren, wenn HM-Nachrichten waehrend der Plot-Erstellung  nicht bestaetigt / abgebrochen werden.

Oder anders: das Problem ist mir bewusst, nur die Loesungen, die mir dazu einfallen sind so aufwendig, dass ich sie nicht angehen will.

[betateilchen]

Ich schließe mich dem Tenor von Udo an.

Das muss ich mir im Kalender notieren

Z.Bsp. wer auf einem FritzBox mit CUL+CUL_HM groessere Plots berechnen will, der hat ein Problem. Der moege entweder kein Fritzbox, kein HM,  kein CUL oder keine Plots haben.

Und das auch. Ein denkwürdiger Tag heute.

Grundsätzlich vertrete ich weiterhin meine Meinung, dass nicht alles, was technisch möglich ist, auch Sinn macht. Vor allem wenn es um die Hardwareauswahl der Plattform geht, auf der man beabsichtigt, fhem einzusetzen.

Irgendwann müssen wir an den Punkt kommen, wo das auch ganz klar und unmissverständlich kommuniziert wird. Ich denke z.B. nicht, dass die von martin beschriebenen timing Probleme auch auf Plattformen wie cubietruck oder beaglebone black auftreten. Einen RaspberryPi habe ich nur noch als Entwicklungs- und Testumgebung im Einsatz, dort ist aber keinerlei Kommunikationshardware angeschlossen.

Das Forken/Threaden wäre doch auch nur die halbe Wahrheit bei der Suche nach einer Lösung: Ich habe dann zwar mehrere Prozesse, aber ich habe doch deshalb keine bessere Hardware. Und nicht alles, was timingprobleme verursacht, ist "nur" eine Softwarefrage.

[justme1968]

ja klar gibt es die. wobei die betonung auf system und auf disziplin liegt. fhem ist kein system in diesem sinn sondern ein prozess der neben anderen auf mehr oder weniger geeigneter hardware läuft. und was die disziplin angeht ist es schwierig wenn es viele mehr oder weniger inkorporierte entwickler gibt die oft nur das eigene modul im auge haben.

auch an konzepten wie ipc, blockieren oder select haben manche sicher zu knabbern.

der ansatz langläufer zu forken ist sicher ein baustein bei der lösung. aber auch nur dann wenn nicht jedes mal neu geforkt wird. sonst
hat es schnell gar keinen oder sogar den gegenteiligen effekt.

deshalb denke ich das ein größer schritt in die richtige richtung wäre eine kommunikationsinftastruktur
die transparent zwischen  abgeschottet modulen oder modulgruppen arbeitet. auf basis der bisherigen dispatch/parse/select/set/get/...

damit könnte das auf einer höheren ebene als fork einfacher vermitteln.

vielleicht sogar transparent für bestehende module die probleme machen.

gruss
  andre

[betateilchen]

auch an konzepten wie ipc, blockieren oder select haben manche sicher zu knabbern.

Das könnte - speziell im Fall fhem - auch an mangelnder der ungeeigneter Dokumentation dieser möglichen Konzepte liegen. Mir hat sich bis heute der Einsatz von Blocking noch nicht erschlossen, auch wenn ich das an manchen Stellen gerne verwendet hätte (z.B. in GDS, wo teilweise mehrere MB große Dateien aus dem Internet geladen werden müssen)

[Dr. Boris Neubert]

Hi,

beim Absetzen eines Kommandos aus dem Webinterface beobachte ich aktuell Delays von 800ms. Diese laufen in der Prozedur FW_Read auf.
Das passiert im deviceview bei einem normalen refresh.
Diese Zeit verzögert das Bearbeiten der Commadqueue in HM. der max delay von 250ms kann nicht eingehalten werden - es kommt zum Abbruch.
Einige Kommandos können aus dem web-interface somit nicht mehr ausgeführt werden, da dieses Delay auch noch korreliert das Kommando IMMER an der gleichen Stelle 'trifft'.

Gibt es Optionen oder ist es in der Mache, FHEM_WEB auf ein max execution time von kleiner 100ms zu begrenzen?

Gruss Martin

Schau Dir mal diesen Patch an: http://forum.fhem.de/index.php/topic,22568.msg160364.html#msg160364

[justme1968]

ja. manches liegt sicher an der dokumentation. aber gerade zu blocking call gibt es einen wiki artikel (http://www.fhemwiki.de/wiki/Blocking_Call) der ein ganz guter einstieg sein kann.

im prinzip geht es um vier teile:
- forken und im hintergrund etwas tun
- dabei freigeben aller parent ressourcen im child um alles sauber zu halten
- rückmelden des ergebnis vom child an den parent
- beenden des child wenn sich eine gewisse zeit nichts getan hat

blocking ist vor allem für dinge die recht selten auftreten und recht lange dauern gedacht.

gds wäre glaube ich der typsiche anwendungsfall was das file im hintergrund holen und dann im parent weiter verarbeiten angeht.

[betateilchen]

es fängt ja schon mit der Frage an, warum das Ding "Blocking" heißt und nicht "NonBlocking" ...

[justme1968]

na weil etwas aufgerufen wird das normalerweise blockieren würde...

aber du hast recht. und bei den http utils ist zumindest das richtig

[martinp876]

Hallo Rudi,

nun, ich rede von dem ganz normalen Frontend. Mir klar, dass ein Plot etwas dauert... danke. Der ist aber hier nicht drin.
Was immer für logs du willst - die Funktion habe ich dir genannt, die Beschreibung auch.

Hier eine Simulation eines beliebigen Device "y":
Mache ein

Code Auswählen Erweitern

{my ($mid,$name,$hId) = ("00A9","y","555555");;\
CommandDefine(undef,"$name CUL_HM $hId");;\
CUL_HM_infoUpdtDevData($name,$defs{$name},"11".$mid."3030303030303030303031333435");;\
CUL_HM_queueUpdtCfg($name);;\
CUL_HM_queueUpdtCfg($_) foreach(grep(/^channel_/,keys %{$defs{$name}}));;\
$attr{$name}{expert}="2";;\
}
apptime clear
dann gehe auf die webseite - bei mir (FB/firefox) http://fritz.box:8083/fhem?detail=y
mache ggf ein refresh
dann ein

Code Auswählen Erweitern

apptime

dann bekomme ich ein

                                name             function    max  count    total  average maxDly
        FHEMWEB:192.168.178.28:51656              FW_Read    844     12      906    75.50      0 HASH(0x11e6558)
                 tmr-CUL_HM_ActCheck       ActionDetector     19      1       19    19.00      5 ActionDetector
        FHEMWEB:192.168.178.28:51662              FW_Read     10      9       39     4.33      0 HASH(0xbaf9d8)
        FHEMWEB:192.168.178.28:51657              FW_Read      4      9       32     3.56      0 HASH(0xf231b8)
                                   y           CUL_HM_Set      3      2        6     3.00      0 HASH(0x10af660); y; ?
                                 WEB              FW_Read      2      1        2     2.00      0 HASH(0x7659c0)
                               iocn1            CUL_Ready      0     25        0     0.00      0
         telnet:192.168.178.28:50028          telnet_Read      0      8        0     0.00      0
                                   y           CUL_HM_Get      0      1        0     0.00      0

das dauert dann 800ms - eigentlich bei fast jeder Seite

Und noch der Log vom Web

18:00:54.846 4: Connection closed for FHEMWEB:192.168.178.28:51656
18:00:54.874 4: Connection accepted from FHEMWEB:192.168.178.28:51797
18:00:54.880 4: HTTP FHEMWEB:192.168.178.28:51797 GET /fhem?detail=y
18:00:55.713 4: /fhem?detail=y / RL:28997 / text/html; charset=UTF-8 /  /
18:00:55.938 4: HTTP FHEMWEB:192.168.178.28:51797 GET /fhem/icons/favicon
18:00:55.953 4: HTTP FHEMWEB:192.168.178.28:51797 GET /fhem/pgm2/style.css
18:00:55.963 4: Connection accepted from FHEMWEB:192.168.178.28:51798
18:00:55.966 4: HTTP FHEMWEB:192.168.178.28:51797 GET /fhem/pgm2/fhemweb_colorpicker.js
18:00:55.975 4: Connection accepted from FHEMWEB:192.168.178.28:51799
18:00:55.979 4: HTTP FHEMWEB:192.168.178.28:51798 GET /fhem/pgm2/svg.js
18:00:55.985 4: HTTP FHEMWEB:192.168.178.28:51797 GET /fhem/pgm2/defaultCommon.css
18:00:55.993 4: HTTP FHEMWEB:192.168.178.28:51799 GET /fhem/pgm2/fhemweb.js
18:00:55.999 4: HTTP FHEMWEB:192.168.178.28:51798 GET /fhem/icons/favicon
18:00:56.005 4: HTTP FHEMWEB:192.168.178.28:51797 GET /fhem/pgm2/fhemweb_multiple.js
18:00:56.013 4: HTTP FHEMWEB:192.168.178.28:51799 GET /fhem/pgm2/dashboard_style.css
18:00:56.023 4: HTTP FHEMWEB:192.168.178.28:51799 GET /fhem/pgm2/fhemweb_svg.js
18:00:56.028 4: HTTP FHEMWEB:192.168.178.28:51798 GET /fhem/pgm2/fhemweb_slider.js
18:00:56.035 4: HTTP FHEMWEB:192.168.178.28:51797 GET /fhem/pgm2/fhemweb_noArg.js
18:00:56.043 4: HTTP FHEMWEB:192.168.178.28:51799 GET /fhem/pgm2/fhemweb_textField.js
18:00:56.049 4: HTTP FHEMWEB:192.168.178.28:51798 GET /fhem/pgm2/fhemweb_time.js
18:00:56.096 4: HTTP FHEMWEB:192.168.178.28:51799 GET /fhem/images/default/Prev.png
18:00:56.103 4: HTTP FHEMWEB:192.168.178.28:51797 GET /fhem/images/default/icoTemp.png
18:00:56.111 4: HTTP FHEMWEB:192.168.178.28:51799 GET /fhem/images/default/shutter_3.png
18:00:56.117 4: HTTP FHEMWEB:192.168.178.28:51798 GET /fhem/images/default/on.png
18:00:56.123 4: HTTP FHEMWEB:192.168.178.28:51797 GET /fhem?cmd={ReadingsVal(%22y%22,%22clear%22,%22%22)}&XHR=1
18:00:56.132 4: /fhem?cmd={ReadingsVal(%22y%22,%22clear%22,%22%22)}&XHR=1 / RL:1 / text/plain; charset=UTF-8 /  /
18:00:56.139 4: HTTP FHEMWEB:192.168.178.28:51799 GET /fhem?cmd={AttrVal(%22y%22,%22room%22,%22%22)}&XHR=1
18:00:56.148 4: /fhem?cmd={AttrVal(%22y%22,%22room%22,%22%22)}&XHR=1 / RL:1 / text/plain; charset=UTF-8 /  /
18:00:56.152 4: HTTP FHEMWEB:192.168.178.28:51798 GET /fhem/images/default/icoHEIZUNG.png
18:00:56.163 4: HTTP FHEMWEB:192.168.178.28:51798 GET /fhem/images/default/icoGraph.png
18:00:56.169 4: HTTP FHEMWEB:192.168.178.28:51797 GET /fhem/images/default/icoSYSTEM.png
18:00:56.177 4: HTTP FHEMWEB:192.168.178.28:51799 GET /fhem/images/default/icoWelt.png
18:00:56.183 4: HTTP FHEMWEB:192.168.178.28:51798 GET /fhem/images/default/icoLog.png
18:00:56.189 4: HTTP FHEMWEB:192.168.178.28:51797 GET /fhem/images/default/icoMail.png
18:00:56.197 4: HTTP FHEMWEB:192.168.178.28:51799 GET /fhem/images/default/icoEverything.png
18:00:56.203 4: HTTP FHEMWEB:192.168.178.28:51798 GET /fhem/images/default/fhemicon.png
18:00:56.327 4: HTTP FHEMWEB:192.168.178.28:51797 GET /fhem?XHR=1&inform=type=status;filter=y&timestamp=1400947262028

Fehlt etwas?