fhemweb - lange antwortzeit bei erstem aufruf nach längerer inaktivität

[chris1284]

hallo,

seit dem ich debian und fhem neu installiert habe, habe ich folgendes merkwürdiges verhalten:

-ich rufe fhem über egal welchen browser auf egal welchem system auf und muss ertseinmal 10-20 sekunden warten bis die seite da ist
-schließe ich dann den browser, öffne erneut die fhem seite ist sie sofort da (gewohnte sverhalten wie vor dem neuinstallieren)
-öffne ich dann ein paar stunden später wieder die website muss ich wieder warten
-arbeiten in fhem geht nach den startschwierigketen immer wie gewohnt schnell

ich habe die config aus dem alten system welches up to date war übernommen somit ist fhem-seitig nichts anderst konfiguriert.
ich hatte er die energiesparoptionen von (einem headless) debian im verdacht aber andere webser wie apache oder die LMS verwaltungswebsite gehen sofort auf.

wo könnte ich bei der fehlersuche noch ansetzen?

[rudolfkoenig]

Vor dem Aufruf der Seite die JavaScript Konsole oeffnen, und in FHEM "attr FHEMWEB verbose 5" aktivieren. Danach die beiden Logs hier anhaengen.

[chris1284]

moin, anbei das log von fhemweb
er braucht 5 sek für dies

2016.03.10 06:12:55 4: WEB_192.168.2.20_56774 GET /fhem?XHR=1&inform=type=status;filter=;since=1457586773;fmt=JSON&fw_id=8354×tamp=1457586757520; BUFLEN:0
2016.03.10 06:13:00 4: Connection closed for WEB_192.168.2.20_56774: EOF

java folgt heute nachmittag, hab ich gerade nicht dran gedacht

[rudolfkoenig]

er braucht 5 sek für dies

Diese Formulierung suggeriert, dass FHEM waehrend der 5sek aktiv ist, was sehr wahrscheinlich nicht der Fall ist. Die mAn bessere Formulierung ist "nach 5 Sekunden wird diese Verbindung vom Browser geschlossen, weil er nicht so viele offene und ungenutzte Verbindungen zu FHEM benoetigt, es sind ja noch 4-6 weitere offen". Und das ist voellig normal.

java folgt heute nachmittag, hab ich gerade nicht dran gedacht

Java hat nichts mit JavaScript zu tun. Siehe auch: http://crashworks.org/if_programming_languages_were_vehicles/
Ich haette gerne die JavaScript Konsole. Und wenn moeglich, ein Screenshot des "Network" Tabs neben der Konsole

[chris1284]

anbei die ausgabe der browserconsole und nochmal das log.
habe mein ich alles in die js.txt kopiert. wenn du das aber nochmal als bild brauchst liefer ich es gerne nach

Java hat nichts mit JavaScript

ist mir als Java ablehnender user bekannt, hatte mich falsch ausgedrückt

[rudolfkoenig]

Die Daten aus .js:

16:47:27.402 Longpoll with filter  fhemweb.js:268:5
16:47:27.411 Rcvd:  fhemweb.js:268:5

und fhemweb.txt

2016.03.10 16:47:45 4: WEB_192.168.2.20_49406 GET /fhem?XHR=1&inform=type=status;filter=;since=1457624863;fmt=JSON&fw_id=12031×tamp=1457624847399; BUFLEN:0

zeigen, dass:
- client und server deutlich abweichenden Zeitstempel haben. Wenn stimmt, bitte fixen.
- die longpoll-Abfrage bei FHEM etwa 1-2 Sekunden nach dem Generieren der .HTML Seite beim Server ankam (1457624863 == 2016.03.10 16:47:43), das finde ich relativ lang, kann aber bei langsamen Komponenten ueblich sein.
- sonst kann ich keine Probleme feststellen.

Ich wuerde weiterhin gerne einen Blick auf den Network Tab des Browsers werfen.
Handelt es sich beim Client um Windows? Wenn ja, dann ist der Virus-Sucher schuld, jedenfalls war es bei den letzten 5 gemeldeten "FHEMWEB-Darstellungsfehler" der Fall

[chris1284]

- client und server deutlich abweichenden Zeitstempel haben. Wenn stimmt, bitte fixen.

wurde angepasst

das finde ich relativ lang, kann aber bei langsamen Komponenten ueblich sein.

würde ich ausschließen da die Komponenten zum einen sich nicht geändert haben und es vor dem neuaufsatz ging und genug leistung vorhandne ist

Ich wuerde weiterhin gerne einen Blick auf den Network Tab des Browsers werfen.

liefer ich noch

Handelt es sich beim Client um Windows? Wenn ja, dann ist der Virus-Sucher schuld, jedenfalls war es bei den letzten 5 gemeldeten "FHEMWEB-Darstellungsfehler" der Fall

ja windows. virus-sucher schließe ich aus da sich der nicht geändert hat (außer die virusdefinitionen natürlich) und auch keine virus-sucher-browser-plugins installiert sind.

[rudolfkoenig]

würde ich ausschließen da die Komponenten zum einen sich nicht geändert haben und es vor dem neuaufsatz ging und genug leistung vorhandne ist

Ich meinte das nicht als Erklaerung fuer das eigentliche Problem, sondern nur als allgemeine Beobachtung.

virus-sucher schließe ich aus da sich der nicht geändert hat

Das haben die anderen am Anfang auch gesagt Ich bin zwar in diesem Fall nicht so sicher, aber ich bitte Dich die Seite auch mal mit einem Nicht-Windows-Geraet aufzurufen.

[chris1284]

anbei nochmal nie netzweranalyse

[rudolfkoenig]

Wenn ich "deine" Farben mit meinem Versuch im Firefox vergleiche, dann dauert in deinem Fall die Namensaufloesung ca 0.2s, Verbindungsaufbau ca 20s, Senden nicht sichtbar, Warten ca 0.4s, Empfang nicht sichtbar. Meine Werte zum Vergleich, ueber HTTPS: 0ms, 2ms, 17ms, 28ms, 0ms.

Ich meine zu erkennen, dass die Verbindung in deinem Fall auch ueber HTTPS laeuft. Wenn ja, dann praezisiere ich meine Hypothese: der Virus-Sucher will neuerdings auch den HTTPS Verkehr analysieren, dazu fuehrt er eine MitM Attacke aus, und braucht 20 Sekunden, um ein gefaelschtes Zertifikat zu erstellen.

[chris1284]

virenscanner kann ich mittlerweile ausschließen. nehme ich am pc die ip geht es wie gehabt schnell. per dns-name nicht.

[Wernieman]

die ip geht es wie gehabt schnell. per dns-name nicht.

Wenn Du per Konsole einen "ping" ausführst, wie lange braucht der erste ping (mit Namensauflösung)?

Welche Namensauflösung verwendest Du?

[chris1284]

Welche Namensauflösung verwendest Du?

Die der Fritzbox, dns der fritte halt. der erste ping dauert wie gewohnt <1ms. wie gesagt, am netzwerk hat sich nichts geändert. nur den server neu installiert. die seiten des apache oder des lms gehen auch sofort auf also liegts ehr am fhem webserver

[Wernieman]

Wenn Aufruf per ip schnell geht, per dns aber langsam liegt es eben NICHT am webserver!

Produziert Dein RasPi regelmäßig Netzwerkverkehr?

Wenn Nein, liegt es genau daran. Die Fritte weiß nicht, ob der Rechner "da" ist und "vergisst" deshalb den dns-Eintrag. Wenn Du dann aufrufst, muß die Fritte es erst ermitteln und DAS dauert.

Lösung:
a) besseren DNS-Server (Du hast doch einen 24/7 RasPi)
b) produzieren von Regelmäßigem Netzwerkverkehr vom RasPi
c) Feste IP auf dem RasPi und Verwendung der "host"-Datei au den Clients
d) ..... noch dieverse andere Lösungsmöglichkeiten

Habe mich übrigens für a) entschieden. Zusätzlich dort allerdings auch noch den dhcp-Server .. das ist die Deluxoption und Ideallösung.

Hinweis:
Ich weiß, das ich es oben etwas vereinfacht erklärt habe, aber besser einfach als Unverständlich

[chris1284]

gegen die theorie spricht einiges:

- warum sollte die fritte mit einem festen eintrag für den server, der auch eine feste ip hat, den dns eintrag nach 8 h verlieren aber für geräte die länger offline sind und einen langen lease haben nicht?
- warum kann die ip sauber in unter <1ms aufgeköst werden? (auch nach leerung dns-cache auf dme aufrufenden client)
- warum sollte dns von heute auf morgen durch den neuaufsatz eines gerätes im netzwerk auf einmal anderst funktionieren als vorher?

zu deinen lösungen

a) besserer dns-server : wieso? die fritte macht was sie soll (löst alles für jeden sauber und schnell auf) da es kein dns problem ist wäre das überflüssig
b) macht der server bereits
c) denkbar schlechteste lösung. dafür haben findige IT-ler ja dns und dhcp erfunden. den aufwand feste ips und hostdateien zu pflegen macht doch heute niemand mehr, auch nicht in einem heimnetzwerk....

zur info:
http://srv01.fritz.box:8084/fhem dauert ewig nach einiger zeit nicht aufrufen
---> warten.......
http://srv01.fritz.box / https://srv01.fritz.box (apachewebsite) geht auch nach 48h nicht aufrufen einer http://srv01.fritz.box site sau schnell
---> warten.......
http://srv01.fritz.box:9000 (LMS-Website) geht auch nach 48h nicht aufrufen einer http://srv01.fritz.box site sau schnell

DNS ist meiner meinung nach komplett auszuschließen. wie gesagt, geht von heut auf morgen ohne änderungen am dns / netzwerk durchzuführen nicht einfach mal nicht mehr 
auflösung funktioniert ja auch wie sie soll. sowohl von intern als auch extern