Hmm. Ich befürchte, dass da wieder ein Problem auf uns zu kommt.
Ich habe seit einigen Tagen iOS9 als Golden Master installiert.
Seitdem kann ich im Safari-Browser die GUI kaum bedienen.
Ein Klick und Mann muss ewig warten. Ich breche dann immer ab und lade die Seite neu. Dann geht es ein wenig schneller.
Die gleichen Probleme gab es damals auch schon.
Und ich befürchte, dass die Golden Master Version auf die finale Version wird.
Hab die GM seit ca. 1h installiert und beobachte ähnliches Verhalten. Werde noch mal ein wenig beobachten ...
Gesendet von iPhone mit Tapatalk
Über VPN von Außen klappt der Zugriff flüssig.
keine Probleme bei TLS-Terminierung am Reverse-Proxy (HAproxy).
Hallo,
habe mit IOS 9 auch wieder dieses unschöne Verhalten unter Safari. Mit Chrome läuft es besser.
Gruß Christoph
Zwar hat es einen Unterschied in den Build-Nummern zwischen GM und Final gegeben. Aber diesbezüglich hat sich nichts zum Postiven geändert. Schade.
Hallo,
ich denke da ist ein Bug in Safari - gerade hat er beim Apfelshop auch einen Timeout hingelegt ;-). Da half auch nur abbrechen und neu laden.
Die Frage ist, ob man hier einen Workaround sucht, oder auf ein IOS Update wartet. Wie schon gesagt Chrome auf dem IPad läuft flüssig.
Grüß Christoph
Hmm. Irgendwie ist bei mir der Wurm drinne.
Auch Chrome auf nem iPhone läuft katastrophal.
Nachtrag: Ich habe für eine Instanz mal SSL deaktiviert und es läuft direkt besser.
Ich habe mit einem iOS 9.0 iPad folgende Szenarien durchgetestet, ohne irgendein Problem zu merken:
- fhem.cfg.demo, 8083
- fhem.cfg.demo, 8085 (Tablet)
- eigene config, als WebApp
- eigene config, HTTPS in FHEMWEB, fuer Smallscreen
- eigene config, HTTPS ueber Apache, umgeleitet auf 8083
Die Ladezeiten sind normal, geschaetzt unter eine Sekunde, je nach Inhalt. Bei fhem.cfg.demo habe ich mit den Widgets (slider, color, etc) rumgespeilt, funktionieren scheinbar ohne Probleme.
Wenn ich irgendetwas fixen soll, dann brauche ich eine genaue Beschreibung, wie ich das Problem nachstellen kann. Offensichtlich ist das Problem zwischen iOS9 und FHEMWEB nicht generell vorhanden.
Eventuell läuft es besser, wenn man die IP benutzt anstatt des Servernamens als URL im Browser. Es könnte ein Problem der Namesauflösung (Bonjour, DNS)
In der Tat läuft es bei mir über die IP auch deutlich flotter. Ich hatte meine Desktop Icons mit IOS9 von IP auf Servernamen umgestellt weil ich gelesen hatte, dass ansonsten VPN on Demand nicht mehr korrekt funktionieren würde.
Zitat von: marcus42 am 21 September 2015, 07:55:30
In der Tat läuft es bei mir über die IP auch deutlich flotter. Ich hatte meine Desktop Icons mit IOS9 von IP auf Servernamen umgestellt weil ich gelesen hatte, dass ansonsten VPN on Demand nicht mehr korrekt funktionieren würde.
OfftopicAm Rande: Ich habe gelesen, dass man nun nicht mehr die IP-Adressen in der xyzmobile.config angeben muss, sondern z.B. die Domain "fritz.box". Dann kann man (endlich) auch wieder mit Hostnamen arbeiten, die nur durch den Suffix ".fritz.box" erweitert werden müssen.
Zum Performance-Problem: Ich bin noch auf der Suche. Ich versuche, den Fehler einzugrenzen, zu reproduzieren bzw. zu provozieren. :-)
- Ich kann auf jedenfall bestätigen, dass das wohl doch nichts mit SSL zu tun hat.
- Mal kann ich mehrere Seitenaufrufe ohne Probleme machen. Dann ist es plötzlich wieder extrem träge.
- Ich habe (doch) keine echten TimeOuts. Es dauert einfach nur sehr lange.
- Ich habe auch nicht das Problem, dass plötzlich keine Stylesheets nachgeladen werden. So war das ja vor kurzem mal der Fall.
- Ich habe einen Raspberry Pi 2b
- Ich greife über eine DynDNS-Adresse auf die Box zu. Auch wenn daheim.
Ich teste gerade den Zugriff via IP und via VPN als Alternative zu DynDNS- Nachtrag: Egal ob per Hostname oder IP; die Probleme bleiben
@Rudolf: Hast du in deinen Konfigurationen zufällig auch Icons im Einsatz? Ich habe jeden Raum und jedes Define mit nem Icon versehen. Nicht, dass hier evtl. zu viele Requests erzeugt werden?
Ich kann das mit dem ipad2 und iphone5s auch bestätigen! Gleiche Symptome wie bei dem alten connectionclose Attribut! @Rudi: kannst du das testweise noch mal einbauen?
ich ebenfalls, iPad mit ios9 nahezu unerträglich iPhone mit ios7 gewohnt schnell!
Greetz
Eldrik
@eldrik: noch ein "mee too" hilft mir (und vermutlich auch der Sache) nicht.
@P.A.Trick: Bitte die Version r8676 auschecken, das war die letzte Version mit closeConn.
Zitat von: rudolfkoenig am 22 September 2015, 08:30:58
@eldrik: noch ein "mee too" hilft mir (und vermutlich auch der Sache) nicht.
das ist mir bewusst, wollte mich damit auch eher als mitlesender "tester" zu erkennen geben.
Greetz
Eldrik
habe auch das problem, dass es unter ios9 sehr langsam und träge ist. im logfile gibt es einträge "FHEMWEB SSL/HTTPS error:"
Die haben dort wahrscheinlich auch vorher schon gestanden.
Zitat von: rudolfkoenig am 22 September 2015, 08:30:58
@eldrik: noch ein "mee too" hilft mir (und vermutlich auch der Sache) nicht.
@P.A.Trick: Bitte die Version r8676 auschecken, das war die letzte Version mit closeConn.
Urgs kann mir jemand sagen wie ich das mache?
Du navigierst auf Sourceforge (https://sourceforge.net/projects/fhem/ (https://sourceforge.net/projects/fhem/)) bis 01_FHEMWEB.pm, da drueckst auf History und waehlst 8676, danach nochmal bis 01_FHEMWEB.pm navigieren, und dann download this file. Habs zum ersten mal gemacht, vielleicht gibts was direkteres.
Das ergibt http://sourceforge.net/p/fhem/code/8676/tree/trunk/fhem/FHEM/01_FHEMWEB.pm?format=raw (http://sourceforge.net/p/fhem/code/8676/tree/trunk/fhem/FHEM/01_FHEMWEB.pm?format=raw)
Oder fuer die Nicht-Weicheier :)
svn co -r8676 svn://svn.code.sf.net/p/fhem/code/trunk/fhem
Zitat von: rudolfkoenig am 22 September 2015, 21:45:43
Du navigierst auf Sourceforge (https://sourceforge.net/projects/fhem/ (https://sourceforge.net/projects/fhem/)) bis 01_FHEMWEB.pm, da drueckst auf History und waehlst 8676, danach nochmal bis 01_FHEMWEB.pm navigieren, und dann download this file. Habs zum ersten mal gemacht, vielleicht gibts was direkteres.
Das ergibt http://sourceforge.net/p/fhem/code/8676/tree/trunk/fhem/FHEM/01_FHEMWEB.pm?format=raw (http://sourceforge.net/p/fhem/code/8676/tree/trunk/fhem/FHEM/01_FHEMWEB.pm?format=raw)
Oder fuer die Nicht-Weicheier :)
svn co -r8676 svn://svn.code.sf.net/p/fhem/code/trunk/fhem
Danke! Ausprobiert und klappt bei mir! ipad2 mit IOS9!
hallo,
soll man Downgraden wenn man das problem hat oder ist ein fix in arbeit? dann wuerde ich auf ein update warten.
Ich kann nur von mir sagen, dass ich an einem Fix erst dann arbeiten werde, wenn ich eine reproduzierbare Anleitung bekomme. Bisher sind hier nicht mal verbose 5 logs aufgetaucht, nur "bei mir tut es auch nicht" Meldungen.
@Rudolf: Deine Aussage ist nachvollziehbar. Aber der Fehler lässt sich halt nicht immer nach einem Standardschema reproduzieren. Ich dachte auch, dass ich eigentlich schon ein paar Infos geliefert hätte.
Egal ob iPhone 1,2,3,4,5,6 oder iPad. Sobald ich mit einem iOS 9-Gerät auf FHEM zugreife, wird der Seitenaufruf nach ein paar Seitenwechseln abrupt und sporadisch langsam.
Dabei scheint es auch keine Rolle zu spielen, ob ich per VPN "reinkomme", intern per Hostname oder per IP darauf zugreife.
Nun habe ich die FHEMWEB-Instanz mal testweise auf "verbose 5" gestellt. Und prompt klick ich mich zu Tode und der Fehler will einfach nicht mehr erscheinen. Irgendwie merkwürdig. Könnte ein Vorführeffekt sein. Ich bleibe am Ball und bleibe bis dahin auf "verbose 5".
Ich habe hier mal ein Log zu einem Zeitpunkt, wo es ins Stocken geraten ist.
Mir faellt auf, dass in deinem Log oefters nach 5 Sekunden Pause ein EOF auftaucht, und es danach weitergeht, ich vermute, hier waren die Verzoegerungen. Kannst du das naechste mal darauf achten, ob diese Theorie stimmt (z.Bsp. bei der Verzoegerug die Uhrzeit merken oder tail -f parallel am laufen haben).
Ich habe auch zusaetzliches Debugging fuer diesen Fall eingebaut und eingecheckt, es taucht aber nur mit verbose 5 auf.
Hallo Rudolf,
ich habe das Problem seit dem Update auf IOS 9 (.0.1) ebenfalls.
Anbei der Debug-Log mit Verbose 5. Die Verzögerung tritt vor den EOFs auf (tail -f). Nach den EOFs gehts dann weiter. BUF: EMPTY
Zugriff über HTTP und IP.
Viele Grüße
Felix
Der naechste Schritt wird leider viel Daten produzieren, ich habe aber keine bessere Idee: bitte in 01_FHEMWEB.pm in der Zeile 326 (vor "if(!$hash->{HDR}) {" Folgendes einfuegen:
Log 1, "$name: $hash->{BUF}";
So, ich habe auch zwei weitere Logs anfertigen können.
Ich fertige am iPhone immer einen Screenshot an, um mir die Uhrzeit zu merken.
Sobald ich dann wieder am Rechner bin, schaue ich dann in Log.
---
Scheinbar muss ich bei einer Aussage zurückruden. Ich hatte gesagt, dass ich per VPN auch die Probleme habe. Die hatte ich auch. Aber irgendwie schaffe ich es nicht mehr, das zu reproduzieren.
Ich greife ständig auf http://fhem.fritz.box zu.
Sobald ich unterwegs bin, wird ein VPN-Tunnel zur Fritzbox 7390 aufgebaut.
Und scheinbar klappt das dann. Ich wundere mich nur, denn das war vor einigen Tagen anders.
Ich habe mein VPN-on-demand aber auch umgestellt und öffne einen Tunnel für alle *.fritz.box-Hostnamen.
Vorher hatte ich die IPs einzeln freigegeben.
Fakt ist aber auch, dass es innerhalb des LANs nicht funktioniert.
@FunkOdyssey: aus deinen logs werde ich nicht wirklich schlau, weil ich nicht weiss, wo/wann die Verzoegerung stattfand. Dank Felix sind wir einen Schritt "weiter", da in seinem Log das Problem deutlich zu erkennen ist.
Was ich verstanden habe: auf einem der Verbindungen erwartet der iOS9-WebKit irgendetwas von FHEMWEB, bevor es weitermacht. Da das nicht kommt, wird die Verbindung nach 30 Sekunden 30 zugemacht, und danach laeuft es weiter. Ich haette jetzt gerne den Header vor dem EOF, um zu raten, was es sein koennte.
Bei mir tritt das Problem weder mit iOS9.0, noch mit 9.1 auf.
Zitat von: rudolfkoenig am 25 September 2015, 10:30:35
@FunkOdyssey: aus deinen logs werde ich nicht wirklich schlau, weil ich nicht weiss, wo/wann die Verzoegerung stattfand.
fhemweb2_log.txtIch habe FHEM um 18:21:14 aufgerufen und es hat direkt gestockt.
fhemweb3_log.txtHier stockte es auch direkt beim Aufruf um 21:15:22 Uhr.
Es gibt bei mir keine Zeilen davor oder danach, die etwas mit FHEMWEB zu tun haben.
Zitat von: rudolfkoenig am 25 September 2015, 09:39:48
Der naechste Schritt wird leider viel Daten produzieren, ich habe aber keine bessere Idee: bitte in 01_FHEMWEB.pm in der Zeile 326 (vor "if(!$hash->{HDR}) {" Folgendes einfuegen:
Log 1, "$name: $hash->{BUF}";
Anbei zwei neue Logs mit einer sehr interessanten Beobachtung:
Ich kann das Verhalten relativ gut reproduzieren. Meist reicht es den Raum zu wechseln. Der erste Wechsel klappt, kurze warten, der Wechsel zurück klappt häufig dann nicht. Aber nur im WLAN! :o
Nutze ich eine VPN-Verbindung über 3G habe ich die 30s Timeouts nicht. Die EOFs kommen trotzdem aber direkt.
Viele Grüße
Felix
Hallo,
nach dem ich festgestellt habe, das Chrome besser läuft, habe ich mal auf meinem IPad die Option "Desktop Seite anfordern" aktiviert. Gefühlt sind es dann viel weniger Aussetzer.
Kann das mal jemand testen ?
Wenn ja, dann würde das die Suche je vielleicht einschränken.
Gruß Christoph
Habe mal ein Log mit verbose 5 mitlaufen lassen.
Es gab ein paar merkwürdige Einträge, z.B.
2015.09.25 20:01:51 4: HTTP FHEMWEB:192.168.1.118:51756 GET /fhem?XHR=1&inform=type=status;filter=room=Bewegungsmelder;since=1443204109;fmt=JSON×tamp=1443204133820
2015.09.25 20:01:54 4: Connection closed for FHEMWEB:192.168.1.118:51768: EOF
2015.09.25 20:01:54 5: BUF: EMPTY
oder
2015.09.25 20:01:51 4: HTTP FHEMWEB:192.168.1.118:51756 GET /fhem?XHR=1&inform=type=status;filter=room=Bewegungsmelder;since=1443204109;fmt=JSON×tamp=14
43204133820
2015.09.25 20:01:54 4: Connection closed for FHEMWEB:192.168.1.118:51768: EOF
2015.09.25 20:01:54 5: BUF: EMPTY
2015.09.25 20:02:23 4: Connection closed for FHEMWEB:192.168.1.118:51769: EOF
2015.09.25 20:02:23 5: BUF: EMPTY
2015.09.25 20:02:23 4: Connection closed for FHEMWEB:192.168.1.118:51766: EOF
2015.09.25 20:02:23 5: BUF: EMPTY
2015.09.25 20:02:25 4: Connection closed for FHEMWEB:192.168.1.118:51751: EOF
2015.09.25 20:02:25 5: BUF: EMPTY
2015.09.25 20:02:25 4: Connection closed for FHEMWEB:192.168.1.118:51759: EOF
2015.09.25 20:02:25 5: BUF: EMPTY
2015.09.25 20:02:28 4: Connection closed for FHEMWEB:192.168.1.118:51767: EOF
2015.09.25 20:02:28 5: BUF: EMPTY
2015.09.25 20:04:37 4: Connection accepted from FHEMWEB:192.168.1.118:51770
2015.09.25 20:04:37 4: Connection closed for FHEMWEB:192.168.1.118:51756: EOF
2015.09.25 20:04:37 5: BUF: EMPTY
2015.09.25 20:04:37 4: HTTP FHEMWEB:192.168.1.118:51770 GET /fhem?room=Arduino_Heizung
Die Aussetzer waren dabei nicht ganz so schlimm. Hatte das Gefühl, dass es vor allem bei den Bildern mit content-encoding gzip länger gedauert hat, aber es hielt sich im Rahmen und wird wohl nur am kodieren liegen.
@Felix: mit deiner Anleitung konnte ich das Problem reproduzieren.
iOS9 hat wohl Probleme mit der if-none-match/HTTP 304 Antworten von FHEMWEB gehabt, und anstatt sich zu beschweren, oder die Daten sofort erneut anzufordern, hat es 30 Sekunden gewartet (warum?).
Ich habe versucht die Antwort jetzt genau RFC konform zu machen, und ich kann das Problem nicht mehr reproduzieren.
Ich habe aber dabei auch die Expires Zeilen repariert (mit dem Nebeneffekt, dass jetzt weniger Dateien angefordert werden, und manche Dateien 15Minuten lang im Browser gecached werden, wie es seit Jahren beabsichtigt war), bin also nicht ganz sicher, woran das Problem eigentlich lag, bzw. ob es nach dem Ablauf (Expires: 15min) das Problem nicht doch auftritt. Bei mir kam das Problem nach 20 Minuten allerdings nicht.
Achtung: fhem.pl muss auch ausgetauscht werden.
soweit ich weiß baut iOS9 zwei TCP Verbindungen auf, eine über WLAN und eine über WAN und die, die schneller antwortet, wird genommen.
Sent from my iPhone using Tapatalk
Mit vorsichtigem Optimismus scheint das Problem gelöst zu sein. Super Sache! Vielen Dank!
Ich werde heute über den Tag mal noch öfters testen.
Felix
Schließe mich an! Klappt! Danke für den Patch.
Moin,
Seit dem Update alles besten!
Danke
Ja, passt wieder alles. Danke sehr!
Viele Grüße
Felix
Hallo zusammen,
zunächst vielen Dank für dieses tolle Projekt und den Patch. Dieser hilft bei meinem IOS9 iPhone insofern, als dass nun der Raumwechsel und auch der Aufruf über Safari wieder in der gewohnten Geschwindigkeit geschieht.
Leider habe ich aber weiterhin die Verzögerung, wenn ich FHEM als Webapp (aus Safari zum Homebildschirm hinzufügen und dann als separtes Icon im Springboard) verwende. Hier scheint er die gesamte Seite beim ersten Auftruf immer neu zu laden und es entsteht der Timeout. Sobald sie geladen ist, ist der Raumwechsel nach dem Patch wieder so schnell wie unter IOS8 (vorher war auch hier der Timeout). Er lädt die Seite bei jedem Appwechsel oder neuen Aufruf der Webapp neu und das Problem tritt so häufig auf.
Ich habe zur Verdeutlichung einige verbose 5 Logs gezogen und während dem Auftreten des Problems per Konsole nachverfolgt. (Datei: Aufruf Webapp.txt)
Zum Vergleich habe ich den Raumwechsel, der sehr schnell erfolgt, ebenfalls mitgeloggt. (Datei: Wechsel Raum in Webapp.txt)
Wäre super, wenn ihr da noch einmal schauen könntet.
Noch habe ich keine Logs. Aber ich habe auch mit dem ersten Aufruf zu kämpfen. Danach fluppt es. Ich melde mich wieder, wenn ich mehr weiß.
@DAREALBA53: Bitte die Logs mit dem aus meinem Post #27 vorgeschlagenen Ausgabe erneut erstellen.
Noch besser waere eine reproduzierbare Anleitung: z.Zt. kann ich es nicht reproduzieren.
@rudolfkoenig: Vielen Dank für die schnelle Antwort. Ich habe das detaillierte Log mit der Änderung in Codezeile 321 (nach dem Patch nicht mehr in 326) erstellt und per Email gesendet.
Sorry, keine Idee nach studieren des Logs.
Ich kann es auch nicht nachstellen. Was z.Zt. nervt, ist die fehlende Reload-Moeglichkeit unter iOS, nachdem Expires gefixt wurde.
Ich konnte das Problem doch reproduzieren: WebApp schliessen, und erneut starten, im Durchschnitt nach 3-4 Versuchen verklemmt es sich. Da ich keine weitere Idee habe, habe ich closeConn wieder eigebaut, und fuer iOS Geraete per default aktiviert. Falls jemand eine bessere Idee hat, bitte melden.
Super vielen Dank für den schnellen Fix! Funktioniert nun wieder wie gewohnt perfekt. Komisch, dass das mit dem Offenhalten der Verbindung nicht funktioniert. Aber das dürfte ja eigentlich die Performance auch nicht stark beeinträchtigen.
ach.... seit closeConn wieder aktiviert wurde, ist auch das Problem mit den riesigen Symbolen wieder da. Frage mich gerade warum immer IOS diese Probleme macht, mit jeder neuen Version das selbe Dilemma. Halten die sich an gar keine Standarts mehr?