IPS 5.1 benötigt mehr Arbeitsspeicher und Webfront reagiert langsamer

IPS ist auf einem Raspi . Seit dem Update von 5.0 auf 5.1 benötigt IPS deutlich mehr Arbeitsspeicher als vorher.

Was mir auch noch aufgefallen ist das Webfront reagiert beim umschalten auf ein andere Seite langsamer zwischen 1-3 sec.
Unter 5.0 reagierte das Webfront sofort.

Benötigt IPS 5.1 generell jetzt mehr Arbeitsspeicher?
Hat sich mit IPS 5.1 grundlegend was an der performance geändert? Oder muss man irgend etwas nachjustieren, dass das Webfront wieder flüssiger läuft.

Ich habe keine derartige Verzögerung bisher bemerkt. Das muss eher an was Speziellem liegen.

Gesendet von iPhone XS mit Tapatalk

Das mit dem Ram kann ich bestätigen. Symcon 5.0 unter Docker ~40MB Ram belegt, mit 5.1 jetzt ~240MB Ram.

Das mit der Verzögerung ist nur in den Unterputz Display´s dort laufen mini Rechner. Am win Rechner ist diese Verzögerung nicht.

Bin nochmal auf 5.0 zurück. Hier ist auch an den Display´s keine Verzögerung beim Wechseln im Webfront. Also muss IPS 5.1 etwas anders umsetzen. Lädt jetzt nicht IPS 5.1 beim Reiter Wechsel im Webfront etwas seit 5.1?

habe die erhöhte RAM Auslastung ausmachen können. Habe fast alle Logfiles gelöscht. und in den Spezialschaltern die Logfiles begrenzt . Seither läuft der Arbeitsspeicher nicht mehr voll. Unter 5.0 war das nicht so.
Hatte erst die RTSP Streams in verdacht, weil dass das Einzige war was neu bei 5.1 dazu gekommen ist bei mir. Aber die waren es nicht.

IPS Team ist das so gewollt, ist das so in Ordnung oder habe ich was falsch eingestellt?

Das sollte so nicht sein und ich kann mir nicht wirklich vorstellen, woran das liegt. Hattest du evtl. das Logging von RTSP Steams aktiv und diese haben dir die Logs „zugemüllt“?

paresy

Hallo,

ich kann die Verzögerungen bei der 5.1 bei mir auch beobachten, sofern ein eher schlanker Client (Raspberry mit 7" Display oder Fire HD8) zum Einsatz kommt, beim Laptop oder iPad treten die „Probleme“ hingegen nicht auf.

Meine Problemseite besteht aus 4 Dummy-Instanzen und 17 Links zu Variablen, auf den Seiten mit weniger Variablen, sind die Aufrufe deutlich schneller.

Was mir noch aufgefallen ist:

  1. Fully Kiosk ist langsamer als Silk (amazon)
  2. webfront.info erscheint schneller als mein lokales Symcon zu sein -> kann es auch an der Server-Performance (auch Raspberry) liegen?

Bin für jegliche Hinweise dankbar, die zu einer Lösung führen könnten. Derzeit ist es leider z.T. etwas zu langsam, sodass man gerne ein zweites mal drücken möchte :wink:

Viele Grüße,
Dennis

Sind da wirklich nur 17 Variablen in dem betroffenen WebFront? Wie viele Variablen hast du denn insgesamt in deinem System? Ist es noch ein Raspberry Pi 1?

Wir fahren unsere Demo mit einer SymBox welche von der CPU Leistung ähnlich dem RPi 3 ist.

paresy

Hallo paresy,

ich kann die Verzögerungen auf einem Samsung Tablet (Galaxy Tab A 10.1) nach dem Update auf 5.1 bestätigen. Je mehr Variablen auf einer Seite, desto länger dauert der Aufbau (bei 48 Variablen ca. 2-3 sek.).
Insgesamt habe ich 1640 Variablen.
Das Webfront läuft auf dem Tablet im Chrome-Vollbildmodus.
IPSymcon läuft bei mir auf einem RPi 3B.

Öffne ich das Webfront auf einem Win-PC aktualisieren sich die Seiten deutlich schneller, daher kann es wohl nicht (nur) am RPi liegen.

Gruß
Marwin

Insgesamt sind bei mir knapp 830 Variablen im System, auf der betroffenen Seite im WebFront sind es „nur“ 17 (inkl. derer die zeitweise ausgeblendet sind), im gesamten Webfront natürlich schon ein paar mehr. Der Raspberry, auf dem Symcon läuft, ist ein 3 B+.

Beste Grüße,
Dennis

Kann die Verzögerungen beim Webfront ebenfalls bestätigen. Umschalten zwischen Tabs bzw. Seitenwechsel braucht 3-7 Sekunden auf Android Tablets (Lenovo Tab2 A10) . Unter IPS <= 5.0 keine Performanceprobleme, erst ab 5.1. Leistungsfähigkeit des Client scheint eine deutliche Rolle zu spielen: auf einem leistungsfähigen Windows Client keine spürbare Verzögerung. Seiten, die betroffen sind haben >100 Variablen, davon immer ca. 80% als hidden markiert. IPS Server ist Intel core i5. Sehr unschöner Zustand, da Tablets als Display kaum mehr nutzbar wg. der Verzögerungen.Was hat sich geändert (Umstellung Dart bzw. Websockets?) bzw. gibt es Abhilfe?

@Hannibal: Wie sieht es bei dir mit Tabwechseln aus? Es klingt bei dir so als wenn die initiale Ladezeit ein Problem darstellt.

@darx: Bisher ging ich davon aus, dass dies ein „Server“ Problem wäre. Falls es ein Client Problem ist, würde ich woanders suchen müssen. Wir haben natürlich einiges zur Dart 1 auf Dart 2 migration geändert - rein von der Performance wäre mir aber nicht bewusst, dass es dort Probleme gibt. Ich würde noch einmal abwarten, ob die anderen ebenfalls eher das Problem Client-Seitig haben, oder dies doch eher ein Server-Problem ist.

paresy

Sorry, paresy, wenn es missverständlich war: Bei mir geht es auch um die Tabwechsel.

Beim initialen Aufruf habe ich noch nichts gemerkt, halte ich schlicht und einfach auch für nicht so relevant.

Viele Grüße,
Dennis

@paresy

Bin nicht sicher, ob es wirklich der Client ist. Bei leistungsfähigen Clients ist es zwar nicht oder „kaum“ spürbar, aber wenn man die Aufrufe profiled („Creating CategoryVariable“ … etc.), dann wird auch da deutlich, dass es deutlich langsamer geht. Bei einem schwachbrüstigen Client ist der Effekt dann massiv. Habe es auf unterschiedlichen Tablets und Win-Clients ausprobiert. Browser ist durchgehend neuste Chrome Version bzw. FullyKiosk. Die Probleme bei der Antwortzeit scheinen praktisch proportional zur Anzahl der Variablen zu sein - wenig Variablen: subjektiv ok, je mehr Variablen, gleichgültig ob angezeigt oder hidden, desto länger dauert es alles. Das Durchlaufen der für eine Seite aufzubauenden html Struktur, also die ganzen Creating CategoryVariable, Creating CategoryLink etc. Aufrufe scheinen deutlich länger zu brauchen als unter IPS <=5.0

Initialer Aufruf des Webfront scheint ebenfalls länger zu dauern, was logisch erscheint, da ggf. für die anzuzeigende Seite dieselbe Problematik auftritt wie für Tab-Wechsel beschreiben.

Wahrscheinlich würde es etwas helfen, die versteckten / hidden Variablen NICHT durch das Webfront zu laden , sondern erst auf Anforderung, um die Last niedriger zu halten.

Dirk

Hi paresy,

ich habe eben noch mal mit einer Testumgebung (Docker) rumgespielt und ein paar Variablen sowie Dummy Instanzen angelegt.

Wenn ich diese direkt im Webfront anzeigen lasse ist der Tab-Wechsel erheblich schneller, als wenn ich für das Webfront nur mit Links arbeite. Bei meinem produktiven Webfront sind alle Variablen einzeln verlinkt, ist das vielleicht gar nicht vorgesehen?

Vielleicht hilft es bei der "Fehler"suche ja etwas…

Danke und viele Grüße,
Dennis

habe es nicht explizit getestet, aber 90% meiner Variablen sind ebenfalls als Links im Webfront. Könnte daher tatsächlich mit den Links zusammenhängen…

Korrektur: bei mir sind es i.w. NICHT einzelne Links auf Variablen, sondern Links auf Dummy Instanzen, die untergeordnete Variablen haben.

Dirk

also ich habe das nochmal beobachtet. Habe IPS5.1 auf einem Raspi laufen.Bei mir sind im Webfront auch hauptsächlich links.

  • Webfront unter einem flotten win Rechner gibt es keine Verzögerung beim Tabwechsel.
  • Webfront direkt auf dem localhost Pi gibt es Verzögerungen beim Tabwechsel.
  • Webfront auf dem UP Display mit mini Rechner treten die gleiche Verzögerungen auf.

Wie schon in den vorherigen Beiträgen genant ist mir auch aufgefallen, je weniger Leistung der Rechner hat in dem das Webfront aufgerufen wird desto länger die Verzögerung beim Tabwechsel. Könnte mit den Variablenanzahl
zusammenhängen. Bei den Tabs, die mehr verlinkte Variablen haben dauert das laden länge wie bei den anderen mit weniger.

Das sollte so nicht sein und ich kann mir nicht wirklich vorstellen, woran das liegt. Hattest du evtl. das Logging von RTSP Steams aktiv und diese haben dir die Logs „zugemüllt“?

Nein das war nicht der Fall. Logging der RTSP Streams war nicht aktiv.

Was ich aber beobachtet habe. Wenn man den Dienst neu Startet und keinen Streams öffnet läuft der Arbeitsspeicher nicht voll.
Am WE habe ich viel Streams geöffnet und geschlossen und siehe da IPS nimmt plötzlich wieder 71% des Arbeitspeichers
in Anspruch. Muss dzu sagen ich abe auch 6 Kameras mit RTSP eingebunden, aber das sollte normal nicht das Problem sein.
Für mich macht es den Anschein als würde er die Prozesse der Streams manchmal nicht beenden.

Gibt es eigentlich eine Möglichkeit auf dem Raspi, herauszufinden welche IPS Prozesse da genau am werkeln sind? Weil in den Meldungen und im Logging Datei taucht nichts ungewöhnliches auf.

Hallo paresy, gibt es zu dem Thema etwas Neues? Finde die Performance Probleme nachwievor sehr unschön - musste deswegen meine webfronts umbauen (verteilen von Links auf mehrere Tabs), um akzeptable Antwortzeiten zu bekommen, was aber keine wirkliche Lösung ist. Danke für FB.

Dirk

Da es bisher keinen Hinweis gibt woran es liegen kann (und du bisher fast der einzige bist der betroffen ist) lohnt sich eine aufwendige Suche nach dem Problem bisher nicht wirklich.

paresy