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
Zitat von: martinp876 am 24 Mai 2014, 10:03:19
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.
Zitatbeim 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.
ZitatGibt 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.
Zitatdurch immer mehr UI-Ballast wird das Frontend immer noch langsamer.
Frueher war eh alles besser.
ZitatUnd 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
ZitatEinem 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.
ZitatZitatIch 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
Zitatein 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.
Zitatso 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.
Zitatwenn 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....
Zitateine 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
Zitatmit 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.
Zitat von: martinp876 am 24 Mai 2014, 12:38:29
Ich schließe mich dem Tenor von Udo an.
Das muss ich mir im Kalender notieren 8)
Zitat von: rudolfkoenig am 24 Mai 2014, 14:12:09
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.
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
Zitat von: justme1968 am 24 Mai 2014, 14:46:58
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)
Zitat von: martinp876 am 24 Mai 2014, 10:03:19
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
ja. manches liegt sicher an der dokumentation. aber gerade zu blocking call gibt es einen wiki artikel (http://www.fhemwiki.de/wiki/Blocking_Call (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.
es fängt ja schon mit der Frage an, warum das Ding "Blocking" heißt und nicht "NonBlocking" ...
na weil etwas aufgerufen wird das normalerweise blockieren würde...
aber du hast recht. und bei den http utils ist zumindest das richtig :)
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
{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 cleardann gehe auf die webseite - bei mir (FB/firefox)
http://fritz.box:8083/fhem?detail=ymache ggf ein refresh
dann ein
apptimedann 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
Zitat18: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×tamp=1400947262028
Fehlt etwas?
ZitatFehlt etwas?
Vermutlich.
Auf einem FB7390 kriege ich nach diesem Verfahren
name function max count total average maxDly
WEBS FW_Read 125 17 2036 119.76 0 HASH(0xa4cb80)
FHEMWEB:*.*.*.*:49850 FW_Read 36 8 55 6.88 0 HASH(0x114fc90)
tmr-FW_closeOldClients 31 5 32 6.40 5
FHEMWEB:*.*.*.*:49842 FW_Read 10 10 46 4.60 0 HASH(0x10e0b70)
FHEMWEB:*.*.*.*:49848 FW_Read 10 6 31 5.17 0 HASH(0x10e0f60)
FHEMWEB:*.*.*.*:49841 FW_Read 9 10 45 4.50 0 HASH(0x12124d0)
FHEMWEB:*.*.*.*:49843 FW_Read 9 10 49 4.90 0 HASH(0x10e0900)
FHEMWEB:*.*.*.*:49846 FW_Read 9 10 48 4.80 0 HASH(0x128f3d8)
y CUL_HM_Set 3 12 27 2.25 0 HASH(0xca3498); y; ?
zd ZWDongle_Ready 2 181 32 0.18 0 HASH(0xa4d070)
y CUL_HM_Get 0 6 0 0.00 0 (mit HTTPS!), auf meinem Entwicklung
name function max count total average maxDly
FHEMWEB:127.0.0.1:49861 FW_Read 2 4 2 0.50 0 HASH(0x7f878c97a040)
fbaha FBAHA_Ready 1 306 2 0.01 0 HASH(0x7f878d4c9a98)
FHEMWEB:127.0.0.1:49854 FW_Read 0 5 0 0.00 0
FHEMWEB:127.0.0.1:49858 FW_Read 0 5 0 0.00 0
FHEMWEB:127.0.0.1:49859 FW_Read 0 4 0 0.00 0
FHEMWEB:127.0.0.1:49860 FW_Read 0 2 0 0.00 0
KM271 KM271_Ready 0 306 0 0.00 0
WEB FW_Read 0 15 0 0.00 0
tmr-CUL_HM_ActCheck ActionDetector 0 5 0 0.00 1
tmr-CUL_HM_procQs CUL_HM_procQs 0 161 0 0.00 2
tmr-FW_closeOldClients 0 2 0 0.00 1
y CUL_HM_Get 0 5 0 0.00 0
y CUL_HM_Set 0 10 0 0.00 0
oh -sorry. Der Satz passt nicht zusammen...
port 61229 wird 10mal gerufen - einmal für 800ms. Herausstechen sehe ich den ersten Aufruf - da ist dann erst einmal ruhe für ~800ms
17:02:32.499 4: Connection accepted from FHEMWEB:192.168.178.28:61229
17:02:32.506 4: HTTP FHEMWEB:192.168.178.28:61229 GET /fhem?detail=sdTeam
17:02:33.422 4: HTTP FHEMWEB:192.168.178.28:61229 GET /fhem/icons/favicon
17:02:33.433 4: HTTP FHEMWEB:192.168.178.28:61229 GET /fhem/pgm2/style.css
17:02:33.463 4: HTTP FHEMWEB:192.168.178.28:61229 GET /fhem/pgm2/svg.js
17:02:33.489 4: HTTP FHEMWEB:192.168.178.28:61229 GET /fhem/pgm2/fhemweb_textField.js
17:02:33.516 4: HTTP FHEMWEB:192.168.178.28:61229 GET /fhem/pgm2/fhemweb_time.js
17:02:33.613 4: HTTP FHEMWEB:192.168.178.28:61229 GET /fhem/images/default/icoTemp.png
17:02:33.635 4: HTTP FHEMWEB:192.168.178.28:61229 GET /fhem?cmd={ReadingsVal(%22sdTeam%22,%22alarmOff%22,%22%22)}&XHR=1
17:02:33.644 4: /fhem?cmd={ReadingsVal(%22sdTeam%22,%22alarmOff%22,%22%22)}&XHR=1 / RL:1 / text/plain; charset=UTF-8 / /
17:02:33.681 4: /fhem?cmd={AttrVal(%22sdTeam%22,%22room%22,%22%22)}&XHR=1 / RL:15 / text/plain; charset=UTF-8 / /
17:02:33.722 4: HTTP FHEMWEB:192.168.178.28:61229 GET /fhem/images/default/fhemicon.png
17:02:33.844 4: HTTP FHEMWEB:192.168.178.28:61229 GET /fhem?XHR=1&inform=type=status;filter=sdTeam×tamp=1401030153078
name function max count total average maxDly
FHEMWEB:192.168.178.28:61229 FW_Read 803 10 868 86.80 0 HASH(0x1218048)
FHEMWEB:192.168.178.28:61234 FW_Read 13 3 23 7.67 0 HASH(0x11a5c50)
FHEMWEB:192.168.178.28:61230 FW_Read 9 6 35 5.83 0 HASH(0x127dba0)
FHEMWEB:192.168.178.28:61231 FW_Read 6 5 26 5.20 0 HASH(0x12348b0)
FHEMWEB:192.168.178.28:61232 FW_Read 6 3 16 5.33 0 HASH(0x11985d8)
FHEMWEB:192.168.178.28:61233 FW_Read 6 3 17 5.67 0 HASH(0x12627c8)
Martin, ich bezweifle nicht, dass du ein Problem hast, ich habe es nur nicht nachvollziehen koennen. Vermutlich wuerde uns weiterhelfen, wenn du in FHEM/01FHEMWEB.pm/FW_answerCall() alle 10 Zeilen eine Log-Zeile einfuegst, um das Problem zu lokalisieren.
Btw, was mir aufgefallen ist, dass du die Komprimierung der Inhalte ausgeschaltet hast. Das aendert aber nichts an den angezeigten Antwortzeiten.
Rudi,
hier die Analyse:
53ms FW_updateHashes
660ms FW_roomOverview
110ms FW_doDetail
FW_roomOverview
560ms sort rooms
100ms Berechnung der HTML seite hierzu
sortRooms habe ich benutzt. Das scheint bei mir das hauptproblem zu sein. Abgesehen davon bleiben immer noch 250ms (die bereits reichen, den Ablauf mit HM zu unterbrechen
Gruss Martin
Ich habe gestern die sortRooms Stelle in FHEMWEB bereits optimiert, allerdings nur fuer Leute wie mich, die kein sortRooms verwenden. Ich habe jetzt auch den sortRooms Fall etwas beschleunigt, ein FB7390 braucht mit fhem.cfg.demo und sortRooms statt 44ms nur noch 12ms, ohne sortRooms 1ms. Wieviele "entities" und Raeume hast du, dass es 560ms dauert? fhem.cfg.demo hat 47 entities und 5 Raeume.
Udo:
Zitat... durch immer mehr UI-Ballast wird das Frontend immer noch langsamer...
martinp876:
ZitatIch schließe mich dem Tenor von Udo an
Soso. Quengeln, dass es zu viele Features gibt, diese aber fleissig benutzen.
Zitat von: rudolfkoenig am 26 Mai 2014, 14:30:14
Soso. Quengeln, dass es zu viele Features gibt, diese aber fleissig benutzen.
Wie kommst Du darauf?
Ich nutze weder sortRooms noch Dashboard oder anderen UI-Ballast.
Selbst der codemirror ist auf meinem Produktivsystem nicht im Einsatz.
Ich meinte nur Martin
:)
ZitatSoso. Quengeln, dass es zu viele Features gibt, diese aber fleissig benutzen.
ok - jaja. Features sind ok - notwendig sogar. Nur müssen sie optimiert werden.
Mit HMInfo habe ich auch ein paar langläufer, ich weiss... Die werden aber explizit aufgerufen, nicht implizit. Und was geht wird geforkt.
Ich habe 17 Gruppen ("sorts") und 20 Räume.
An den sorts kann ich evtl sparen. Die Räume misbrauch ich - wie schon einige male gepostet - zum Sortieren. Das ist die einzige methode, auf Entity-gruppen schnell zugreifen zu können (es sein den, man schreibt ein eigenes frontend).
Rooms werden immer in einem frame angezeigt und ich kann mit einem Click eine Gruppe von entities sehen:
Alle Lichter
alle Aktoren im Wohnzimmer
alles was heizung ist
....
Es ist quasi ein konfigurierbarer Direkt-link - ein click und ich habe eine Sammlung von Zuständen eines Bereichs - incl zugriff darauf.
Group gibt dies bei weitem nicht her.
Ich kenne keine Alternative in FHEM hierzu.
Ich könnte gerne die Liste der rooms fix eingeben - was das ganze sort spart. Wenn man also eine roomliste anlegt und die Reihenfolge der Eingabe auch die Reihenfolge in Web ist, wäre dies optimal. Geht dynamik verloren... halte ich aber nicht fr schlimm.
Nicht vergessen: Auch ohne sort haben wir schon 250ms!! Eigentlich bereits zu viel.
Gruss Martin
Nochmal die Frage: Wieviele Entities hast Du? Und wieviel hat mein Patch von heute gebracht?
Was meinst Du mit 17 Grouppen ("sorts")? sortRooms oder das group Attribut?
Hallo Rudi,
In sort lege ich quasi die Reihenfolge der Rooms fest. Da stehen 17 drin. Da kommen nur wenige dazu...
Übrigens wäre mein Vorschlag für die Codestelle
my @rlist;
if(AttrVal($FW_wname, "sortRooms", "")) { # Slow!
@rlist = split( " ", AttrVal( $FW_wname, "sortRooms", "" ) );
foreach my $r (sort keys %FW_rooms){
push @rlist,$r if (!grep /$r/,@rlist);
}
} else {
@rlist = sort keys %FW_rooms;
}
Anstatt 500ms messe ich noch 8ms.
Auch bei 100 rooms und kompletten sort sollte das kein Problem sein.
Mit deiner Lösung sind es auch nur noch 80ms - faktor
auch nicht schlecht.
p.s. Die Zeiten beziehen sich nur auf sortRoom. Der Vergleich ist also zu 660ms (orginal) zu sehen
Ich habe mit deiner Loesung auch kein Problem, allerdings ist es nicht ganz kompatibel zu den alten Code von justme1968, und ich weiss nicht, ob er an dem Regexp haengt oder nicht.
Und zum dritten mal: wieviele Entities hast Du?
hängen ist der falsche ausdruck. ich verwende das feature. und auch noch andere. siehe unter anderem die diskussion damals mit dem anderen martin und auch mit markus.
wenn das ganze tatsächlich so ein geschwindigkeits problem ist wäre ich eher dafür die komplette sortierung jeweils so lange zu cachen bis sich die raum liste ändert.
Ich habe keine Idee, wie man das einigermassen elegant loesen soll, room ist doch kein lokales Attribut.
ich geh mal Popcorn holen, das könnte hier noch recht lustig werden 8)
elegant ist etwas anderes...
aber ich könnte mir vorstellen das man sich in CommandAttr den timestamp der letzten änderung für das room attribut merkt und darauf prüft.
oder gleich für jedes möglich globale attribut. dann könnte man %FW_rooms, %FW_groups und %FW_types auch noch connection übergreifend cachen. vielleicht ist %FW_hiddengroup auch noch ein kandidat?
und Rudi weiss immer noch nicht, wieviele entities martin im Einsatz hat :P
alles in allem nur 117 in diesem Setup (eigentlich wenig, meine ich)
was hat es mit der regexp auf sich? Die in FW_roomIdx?
Wenn ich es richtig sehe werden die räume mit '^$' eindeutig identifiziert - also nicht alles, was beispielsweise mit OG beginnt oder OG enthält. Dann wäre wohl kein Unterschied zu meiner Lösung - ausser, dass ich nicht suche, ob der raum aus sortRooms auch in FW_rooms existiert. Das halte ich nicht für notwendig.... wenn der user den einträgt... kann man aber auch einfach filtern, so man will.
Wo ist das Feature? Ich sehe es auch keine Beschreibung...
oder gibt es noch eine andere regexp?
ps: gut aufgepasst Udo - danke
du hast recht. die doku lässt mal wieder zu wünschen übrig.
mit der aktuellen version kann man sehr wohl z.b. DG.* OG.* EG.* schreiben und es wird dann danach gruppiert und innerhalb der gruppierung automatisch alphabetisch sortiert und danach alles andere alphabetisch dahinter. oder auch 2.* 1.* 0.* um automatisch 2 2.1 2.2 2.3 1 1.1 1.2 1.3 0 0.1 0.2 0.3 zu bekommen.
ah - ok. Der .* kommt aus dem Attribut... klar.
das wäre in der Doku gut - sollte sicher heissen:
sortRooms
Space separated list of rooms to override the default sort order of the room links. Example:
attr WEB sortRooms DG.* OG.* EG.* Keller.*
sortRooms
Space separated list of regex to override the default sort order of the room links. Example:
attr WEB sortRooms DG.* OG.* EG.* Keller.*
das spart noch einmal die Hälfte zu Rudis Vorschlag - und sollte justme1968 auch genügen.
FW_roomIdx kann man löschen.
Sollte die roomListe nicht gleich in FW_updateHashes() generiert werden? Und das könnte man triggern, wenn attr room, group, model oder subType geändert werden. Und bei der Definition (wegen TYPE).
Wird boot evtl etwas langsamer - aber sonst wird es schneller.
Generell wäre das m.E. näher an einer echtzeit-anwendung - vorbereitende Berechnungen.
my @rlist;
if(AttrVal($FW_wname, "sortRooms", "")) {
my @sortBy = (split( " ", AttrVal( $FW_wname, "sortRooms", "" ) ),".*");
my %sHash;
my $index;
foreach my $r(keys %FW_rooms){
$index = 0;
foreach(@sortBy){
last if ($r =~ /^$_$/);
$index++;
}
$sHash{$r} = substr("000$index",-3)."-$r";
}
@rlist = sort { $sHash{$a} cmp $sHash{$b} } keys %FW_rooms;
} else {
@rlist = sort keys %FW_rooms;
}
Hab kein Problem mit dem Code, wenn justme1968 auch seinen Segen dazu gibt.
ZitatUnd das könnte man triggern, wenn attr room, group, model oder subType geändert werden. Und bei der Definition (wegen TYPE).
Das geht aber nur mit einem event beim Attribut-Aendern, und da bin ich noch dagegen.
ZitatGenerell wäre das m.E. näher an einer echtzeit-anwendung - vorbereitende Berechnungen.
Ich bin nicht daran interessiert, FHEM "echtzeit-faehig" zu machen, mAn ist das sehr viel Aufwand um etwas zu loesen, was man viel einfacher auch erreichen kann, z.Bsp. mit einem separaten Prozess fuer die HM-ACKs oder mit "ordentlichen" Hardware (HMLAN statt CUL oder bessere CPU). Oder einfach damit leben, dass manchmal HM-Befehle kein ACK kriegen.
Wie sollte man z.Bsp. das SVG-Problem loesen? Fork fuer jeden der angeforderten SVGs auf dem Fritzbox laesst die Kiste abstuerzen, ohne Fork kann ich keine 100ms garantieren. Selbst wenn ich SVG (irgendwannmal) in JS nachgebaut habe, muss FHEM etliche MB lesen + komprimieren, das kann auch mehr als 100ms dauern.
Zitatwenn justme1968 auch seinen Segen dazu gibt
ich weiss ja nicht ob man das segen nennen sollte aber für meine anwendungsfälle und tests funktioniert es.
ZitatDas geht aber nur mit einem event beim Attribut-Aendern, und da bin ich noch dagegen.
schau dir noch mal weiter oben den vorschlag mit dem timestamp beim ändern der attribute an. das geht ganz ohne events. und da nur timestamps gemerkt und verglichen werden sollte es auch recht effizient sein.
ZitatWie sollte man z.Bsp. das SVG-Problem loesen?
man muss ja nicht für jeden plot forken sondern könnte auch ein mal nur für das ganze web frontend oder ein mal für alle plots.
Zitatschau dir noch mal weiter oben den vorschlag mit dem timestamp beim ändern der attribute an.
Hardcoding in fhem.pl fuer ein spezielles Modul, damit auf lahmen Hardware und viel Peripherie unter Verwendung eines bestimmten Attributes ein Webaufruf 30ms schneller wird. Was an sich noch kein Problem loest. Sehr unsympatische Loesung.
Zitatman muss ja nicht für jeden plot forken sondern könnte auch ein mal nur für das ganze web frontend oder ein mal für alle plots.
Oder man nimmt ordentlichen Hardware. Oder man ignoriert das Problem :)
Hardcoding in fhem.pl fuer ein spezielles Modulnein. nicht hard kodiert für ein modul. für alle globalen attribute. und an allen stellen verwendbar die attribute über alle devices zusammen suchen müssen.
wenn in CommandAttr ein $attrTimestamp{<attr>} gesetzt wird und im modul mit dem lokalen timestamp der hash erzeugung verglichen wird ist beides völlig entkoppelt.
Oder man nimmt ordentlichen Hardware. Oder man ignoriert das Problemja. und vor allem keine fritz box :)
ZitatOder man nimmt ordentlichen Hardware. Oder man ignoriert das Problem
hm - ich denke keines von Beidem ist hinreichend. Oder seid ihr mit einem "manchmal - schaltet er" zufrieden? Da haben andere schon bei deutlich selteneren Fehlschaltungen Probleme (zurecht).
ZitatIch bin nicht daran interessiert, FHEM "echtzeit-faehig" zu machen,
schade. Zumindest irgendeine Vereinbarung über timings wäre schon. Die Probleme steigen... Das system wird (zu recht) komplexer und langsamer.
Die Aussage ist also, dass man - will man ein Timing erzeugen - den echtzeit-anteil forken muss... das geht aber leider nicht on the fly - das dauert schon einmal zu lange... müsste man parallel laufen lassen....
Unschön ist z.B. auch, dass ein "totes" ethernet-IO ständig (alle 5 sec) gepollt wird (sinnlos, nichts probiert wird) und jede Min 3sec FHEM blocktiert... USB muss ich noch einmal ansehen...
Auch mit schnellerer HW sind die 3 sec hart kodiert. Eine IO Ersatzschaltung hat mit den 3 sec immer Probleme.
Zitat von: martinp876 am 27 Mai 2014, 20:06:14
schade. Zumindest irgendeine Vereinbarung über timings wäre schon. Die Probleme steigen... Das system wird (zu recht) komplexer und langsamer.
Das halte ich für aussichtslos bei der Fülle an Systemen und Betriebsystemen.
M.E. ist der vorher schonmal angebrachte Vorschlag, die Verarbeitung der HM-Befehle nebenläufig zu fhem zu gestalten, für aussichtsreich. Ich meine damit einen Serverprozeß analog zu owserver, der die Kommunikation mit den HM-Geräten puffert, und über TCP-Sockets mit FHEM kommuniziert.
Viele Grüße
Boris
Hallo Boris,
darauf läuft es wohl hinaus - alles ander ist hoffen.
Ich bin mir nicht sicher, ob OW diese timing-komplexität hat. Ich muss je HM device einen Kommandstack verwalten. Ein Device kann wahlweise zwischen IOs umschalten. Empfangssignale müssen die Sendesignale Triggern. Das IO device darf nicht beliebig senden sondern muss messages der unterschiedlichen HM-Devices sortieren und queuen.
Da müssen einige Teile aus CUL_HM in den Server-threat ausgelagert werden (und dann wieder zurückgegeben, damit man auswertungenmachen kann).
Ist ein größeres Projekt.
Natürlich müssen auch die IOs (CUL und HMLAN) 'ausgelagert' werden.
Gruss Martin
Zitatwenn in CommandAttr ein $attrTimestamp{<attr>} gesetzt wird und im modul mit dem lokalen timestamp der hash erzeugung verglichen wird ist beides völlig entkoppelt.
Das ist natuerlich eine viel elegantere Idee. Leider reicht so noch nicht, weil auch Attribut loeschen, Geraet anlegen, Umbenennen, Loeschen, Modifizierern beachtet werden muss. Ich habe deswegen $lastDefChange eingefuehrt, was in all diesen Funktionen hochzaehlt. Es stellte sich raus, dass das auch noch nicht reicht, weil eine TCP-Verbindung auch ein Geraet erzeugt und loescht, damit war kein Caching-Effekt zu beobachten. Daraufhin habe ich TEMPORARY Geraete aus der Zaehlung ausgenommen.
Es scheint bei mir zu funktionieren, mit der etwas schalen Nachgeschmacks der "Viel Aufwand fuer was eigentlich?".
Hoffentlich gibt es noch weitere Nutzer der Variable.