fhemweb FW_Read zu langsam

[rudolfkoenig]

Fehlt etwas?

Vermutlich.

Auf einem FB7390 kriege ich nach diesem Verfahren

Code Auswählen Erweitern


                  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

Code Auswählen Erweitern

                    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

[martinp876]

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&timestamp=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)

[rudolfkoenig]

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.

[martinp876]

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

[rudolfkoenig]

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:

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

martinp876:

Ich schließe mich dem Tenor von Udo an

Soso. Quengeln, dass es zu viele Features gibt, diese aber fleissig benutzen.

[betateilchen]

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.

[rudolfkoenig]

Ich meinte nur Martin

[martinp876]

Soso. 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

[rudolfkoenig]

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?

[martinp876]

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

Code Auswählen Erweitern

  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

[rudolfkoenig]

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?

[justme1968]

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.

[rudolfkoenig]

Ich habe keine Idee, wie man das einigermassen elegant loesen soll, room ist doch kein lokales Attribut.

[betateilchen]

ich geh mal Popcorn holen, das könnte hier noch recht lustig werden 

[justme1968]

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?