FHEMWEB unter iOS9 träge und TimeOuts

Begonnen von FunkOdyssey, 15 September 2015, 22:48:11

Vorheriges Thema - Nächstes Thema

FunkOdyssey

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.

marcus42

Hab die GM seit ca. 1h installiert und beobachte ähnliches Verhalten. Werde noch mal ein wenig beobachten  ...


Gesendet von iPhone mit Tapatalk

marcus42

Über VPN von Außen klappt der Zugriff flüssig.

Loredo

keine Probleme bei TLS-Terminierung am Reverse-Proxy (HAproxy).
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Bennemannc

Hallo,

habe mit IOS 9 auch wieder dieses unschöne Verhalten unter Safari. Mit Chrome läuft es besser.

Gruß Christoph
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

FunkOdyssey

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.

Bennemannc

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
Cubietruck, Fhem 5.8
CC-RT-DN|LC-SW2-FM|RC-12|RC-19|LC-SW4-BA-PCB|LCp-SW1-BA-PCB|ES-PMSw1-Pl|LC-Bl1PBU-FM|PBI-4-FM|CC-VD|CC-TC|SEC-SC(2)|RC-KEY3-B|LC-Sw1PBU-FM|PB-2-FM|WDS100-C6-O|WDC7000|LC-Bl1-FM
Module: Dewpoint,FB_Callmonitor,HCS,Panstamp,at,notify,THRESHOLD,average,DOIF

FunkOdyssey

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

rudolfkoenig

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.

setstate

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)

marcus42

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.

FunkOdyssey

#11
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.

Offtopic
Am 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?

P.A.Trick

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?
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

eldrik

ich ebenfalls, iPad mit ios9 nahezu unerträglich iPhone mit ios7 gewohnt schnell!

Greetz
Eldrik

rudolfkoenig

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