Fhemweb sehr langsam, neu Laden dauert "ewig" ios7

[rudolfkoenig]

Vielleicht hilft mein aktueller Stand beim Lokalisieren: iOS Safari macht bis zu 6 parallele Verbindungen beim Laden auf, FHEMWEB bedient diese nur insoweit parallel, dass man nicht "aktiv" wartet. Separate Prozesse gibts nur fuer SVGs.
Wenn Safari meint, dass die Seite fertig geladen ist, wird nur noch eine Verbindung zu FHEMWEB zugelassen. Diesen braucht fhemweb.js fuer longpoll, aber das heisst, dass Safari keine Bilder (.png/.gif) nachladen kann.  Die SVGs werden "inline" in der longpoll Verbindung gesendet, deswegen funktionieren sie. Eine Session-Begrenzung gibts in FHEMWEB nicht, und Speicher-Engpass kommt auch nur fuer Plots mit gesetzten plotfork Attribut in Frage. Selbst das sollte auf einem RPi kein Problem sein, hoechstens auf einer FB.

Koennt ihr folgendes testen:
- Existiert das Problem auch ohne longpoll
- verbose 5 fuer die FHEMWEB Instanz, und mseclog fuer global setzen, und das Problem provozieren. Die 30-Sekunden muessen im Log sichtbar sein, das kurz davor und kurz danach interessiert mich.

[micomat]

Muss ich heute abend mal testen.

Gruß
Markus

[fruemmel]

Hallo Rudolf,

so, getestet. Longpoll auf 0 bringt nichts, auch da bleibt der weiße Bildschirm. Dann sogar deutlich länger.
Im Anhang die Logfiles. verbose=5 für die Web-Instanz, allerdings kommen nur Meldungen mit level 4.

In beiden Fällen kam ohne weitere Bedienung am iPhone nach einer Minute bzw. ohne Longpoll nach fast
zwei Minuten der fertige Screen.

Gruß Wolfgang

[micomat]

interessant...
beim whitescreen genau 5 geoeffnete sessions, genau das hab ich auch beobachtet.

[micomat]

so jetzt eben nochmal getestet...
mein iphone hat jetzt seid bestimmt 45sek nen weißen screen gehabt bevor was angezeigt wurde.
währenddessen

Code Auswählen Erweitern

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53293 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:59233 pi-energy.fritz:cfinger ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53286 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53304 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54067 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53301 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53268 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54066 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53305 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54064 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:56036 fritz.box:1012          ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54062 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53302 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54065 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54063 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:ssh   micoeee-win8.frit:53307 ESTABLISHED


nach dem laden

Code Auswählen Erweitern

Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 pi-fhem.fritz.box:59233 pi-energy.fritz:cfinger ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53268 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53305 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54068 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:56036 fritz.box:1012          ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54062 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:ssh   micoeee-win8.frit:53307 ESTABLISHED

jetzt kann ich problemlos zigmal nacheinander den ios-browser schließen und wieder aufmachen, alles bestens.
öffne ich jetzt webphone auf dem PC:

Code Auswählen Erweitern

tcp        0      0 pi-fhem.fritz.box:59233 pi-energy.fritz:cfinger ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53354 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53353 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53352 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  micoeee-win8.frit:53305 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:56036 fritz.box:1012          ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53351 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53350 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  micoeee-win8.frit:53355 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:ssh   micoeee-win8.frit:53307 ESTABLISHED


und schon habe ich auf iphone wieder nen whitescreen.
es scheint dabei egal zu sein wieviele sessions auf welchem port zu sehen sind.

gruß
markus

[P.A.Trick]

Ich kann das auch bestätigen. Aktuelles IOS7 auf ipad2 und ipod 5 -> gleiches Sympton! Sobald ich auf abbrechen und neuladen klicke funktioniert es schnell (bei allen 3 Ports 8083-85)

[fruemmel]

Ich kann das auch bestätigen. Aktuelles IOS7 auf ipad2 und ipod 5 -> gleiches Sympton! Sobald ich auf abbrechen und neuladen klicke funktioniert es schnell (bei allen 3 Ports 8083-85)

Ist bei mir auch exakt so.

Aber wie oben schon erwähnt: den Effekt habe ich nur auf meinem RPi als FHEM-Server. Verlagere ich die gleiche Installation auf ein debian auf einem schnellen PC, läuft auch auf dem iPhone alles perfekt. Ich habe nur keine Ahnung, wie man dem Grund (ggfls. Timing) auf die Schliche kommt.

[micomat]

hm... ein aehnlich "blockiertes" verhalten kenne ich sonst nur von plots.
wenn ich meinen heizungsraum aufrufe in dem 5 groessere plots drin sind blockier fhem auch solange bis alle plots gerendert sind. aber die werden ja beim blossen aufruf nicht erstellt...

[fruemmel]

hm... ein aehnlich "blockiertes" verhalten kenne ich sonst nur von plots.
wenn ich meinen heizungsraum aufrufe in dem 5 groessere plots drin sind blockier fhem auch solange bis alle plots gerendert sind. aber die werden ja beim blossen aufruf nicht erstellt...

Selbst wenn ich als "Startraum" einen Raum mit nur einem einzigen Gerät anlege, ändert das nichts an dem Effekt mit dem weissen Schirm. Aber eine Blockade seitens FHEM scheidet ja eigentlich sowieso aus, da es auf nicht-Äpfeln das Problem ja auch nicht gibt ...

[P.A.Trick]

Stimmt unter Linux mit Firefox löppt alles perfekt und sauschnell. Ich glaube auch, dass es die Anzahl der gleichzeitig geöffneten Verbindungen ist, mit dem FHEM Probleme hat. Das würde auch zu dem Problem mit dem verschwindenen SVG Icons erklären.

[det.]

...den Effekt habe ich nur auf meinem RPi als FHEM-Server. Verlagere ich die gleiche Installation auf ein debian auf einem schnellen PC, läuft auch auf dem iPhone alles perfekt...

das war für mich der Grund im Herbst 2013 FHEM auf ein Cubie2 Board umzuziehen. Als es nach einiger Zeit da auch anfing, habe ich konsequent alle überflüssigen readings rausgeworfen (event-on-change-reading, event-on-update-reading, do_not_notify 1 etc.) Im Event monitor ansehen was so kommt und alles was man nicht braucht unterbinden - seither sind die Hänger auf dem iPad im größtenteils weg.

[P.A.Trick]

Ich bin aber ein Freund davon diese Kausalität aufzulösen und nicht einfach mit Ressourcen totzuschlagen, besonders da sich mein fhem sonst langweilt!

[rudolfkoenig]

Koennt ihr in 01_FHEMWEB.pm vor der Zeile 386:

Code Auswählen Erweitern

exit if(defined($pid));
folgende einfuegen

Code Auswählen Erweitern

TcpServer_Close($hash); delete($defs{$hash->{NAME}});
und nochmal testen?
P.S: Ich weiss auch nicht wirklich, was los ist, und tappe nur im dunkeln...

[micomat]

Code Auswählen Erweitern

tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62376 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62372 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62359 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62373 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62354 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62368 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62360 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:60187 pi-energy.fritz:cfinger ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54519 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62370 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:56990 fritz.box:1012          ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62367 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62375 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62364 ESTABLISHED
tcp        0    175 pi-fhem.fritz.box:8083  mico.fritz.:62369 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62374 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62365 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62355 ESTABLISHED
tcp        0    236 pi-fhem.fritz.box:ssh   mico.fritz.:62342 ESTABLISHED
tcp        0      0 pi-fhem.fritz.box:8084  mico.fritz.:62371 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8084  mics-iPhone.fritz:54529 TIME_WAIT
tcp        0      0 pi-fhem.fritz.box:8083  mico.fritz.:62363 TIME_WAIT


Habs jetzt mal eingebaut.
Seitdem sind mehr Connections auf TIME_WAIT und gefuehlt auch schnelle wieder weg.
Ich werd mal testen

Markus

[fruemmel]

Es geht voran!

Koennt ihr in 01_FHEMWEB.pm vor der Zeile 386:

Code Auswählen Erweitern

exit if(defined($pid));
folgende einfuegen

Code Auswählen Erweitern

TcpServer_Close($hash); delete($defs{$hash->{NAME}});
und nochmal testen?
P.S: Ich weiss auch nicht wirklich, was los ist, und tappe nur im dunkeln...

Nach dem Tipp von Rudolf kann ich den weißen Bildschirm derzeit nicht reproduzieren. Gefühlt reagiert fhem beim Erstaufbau allerdings
etwas träger als vorher. D. h. vom Anklicken des WebApp-Icons von fhem bis zur Darstellung des Startraumes dauert es ca. 3 Sekunden.
Das muss ich aber noch einmal genauer testen.

Zumindest hat die Änderung definitiv etwas gebracht.

@Rudolf: Lässt das aus Deiner Sicht nun eine Erklärung der Ursache zu? Wenn ich meine subjektiven Tests zusammenfasse bleibt
folgendes Fazit (vor der Anpassung): Langsamer Server oder komplexe fhem-config: Weisser Schirm. Schneller Server / magere config: alles gut.
Weitere Vermutung: langsame Verbindung (DSL/VPN) dann geht es auch mit langsamem Server. Schnelles Netz (WLAN oder WLAN/VPN) geht nicht.

Gruß Wolfgang