# WebVisu extrem langsam / nicht erreichbar



## andreas-w211 (3 Januar 2022)

Hallo,

ich habe folgendes Problem:
Auf einem 
PFC100: 750-8100, 1.5.14.13 (FW: 03.07.14(19))
läuft ein Programm zur Heizungssteuerung (viele Räume, aber nur simpler soll / ist Temperaturvergeich) mit 16 Web-Visualisierungen.
auf die 16 WebVisus grefit jeweils ein HMI per direktlink zu.
Jede Visualisierung besteht aus der Anzeige von 6 bis 10 Temperaturen (Textvariablen) und 3 bis 5 Schiebereglern, mit denen man die Solltemperatur vorgibt.
Die Steuerung habe ich ca. 1 Monat in Betrieb, die Visualisierungen liefen sehr langsam (Bedienung der Schieberegler sehr, sehr zeitverzögert). Seit 5 Tagen kam vereinzelt die Fehlermeldung "An error happened; will automatically restart". Die Fehlermeldungen wurden häufiger bis die Webvisu garnicht mehr geladen hat (dauerhafte Anzeige: "Loading Webvisualization").
Ich habe dann die Zykluszeit der Webvisu geändert (von 20ms bis 400ms alles versucht, Aktualisierungsrate ebenfalls angepasst), jetzt wird auf den HMI´s nur noch "503 Service Unavailable" angezeigt.
Die Prozessorauslastung (ProzessorLoad) liegt unter 25%, die Zykluszeiten der Tasks alle weit vom eingestellten Intervall entfernt (Bsp: Intervall: 150ms, Zykluszeit ca. 5ms, max. Zykluszeit ca. 6ms).
Aktuell habe ich eine Aktualisierungsrate von 40ms, Intervall der Visu-Taskt 40ms, und eine "Stadardgröße Kommunikation" von 1000 eingestellt. Diese Werte hatte ich auch schon deutlich vergrößert ohne eine Verbesserung.
Die Bedienung der Visu innerhalb von e!Cockpit läuft mit geringer verzögerung, ein bediennen der Schieberegler ist gut möglich. 
Die Steuerung habe ich auch mit einem Reset (kalt) neu gestartet, die Webvisus sind weiterhin nicht erreichbar.
Der Status ändert sich auch nicht, wenn ich nur ein HMI physikalisch anschließe.
Wo liegt der Fehler? Wasist da überlastet? Wie kann ich die Webvisu wieder erreichen und dann beschleunigen?

Vielen Dank für Tipps und Hinweise.
Andreas


----------



## KLM (4 Januar 2022)

Moin, versuch mal die Aktualisierungsrate langsamer, nicht schneller, einzustellen. Auch die Speichereinstellung für die Clients kannst Du mal testen, d.h. im Visualisierungsmanager in der Registerkarte Allgemein unten rechts die Checkbox für erweiterte Einstellungen setzen und dann die max. Anzahl der Clients halbieren, also auf 50, und den Speicher verdoppeln, von 40000 auf 80000.


----------



## andreas-w211 (4 Januar 2022)

Hallo KLM,

die Aktualisierungsrate und Zykluszeit für die Webvisu hatte ich sowohl nach oben als auch nach unten angepasst. Von 40ms bis 400ms, auch mit verschiedenen Speichergrößen der jeweiligen Visu.
Heute habe ich die Speichereinstellungen der Clients verändert, wie von dir vorgeschlagen. Leider ohne Erfolg. Angeblich passt sich der Speicher auch automatisch an (steht so in der Hilfe, "dynamische verdopplung"). Ich kann die Webvisu jetzt gar nicht mehr erreichen (Meldung "503 Service Unavailable", auch ein Reset (Ursprung) hat nicht weitergeholfen. Das WBM kann ich erreichen.
CPU- Auslastung (jetzt zw. 16 und 20%) und die Taskzeiten sehen unkritisch aus.
Könnte irgend ein Speicher sich füllen und mittlerweile zu voll sein? Damit könnte man zuindest die langsame verschlechterung des Zustandes erklären.


----------



## KLM (4 Januar 2022)

Service Unavailable spricht dafür, dass der Webserver abgestürzt ist. Neu starten kannst Du den durch einen Neustart des Controllers oder über ein Skript in /etc/confic-tools/ namens restart_webserver.


----------



## andreas-w211 (4 Januar 2022)

Den Webserver habe ich wieder zum laufen bekommen. Anscheinend war ich das erste mal beim Neustart zu ungeduldig und habe die Spannung zu früh wieder zugeschaltet. Die Visu läuft wieder, jetzt muss ich noch etwas gegen die zu starke Verzögerung beim betätigen der Schieberegler tun. Das anpassen der Zykluszeit und der Aktualisierungsrate hat nicht viel gebracht, das umstellen des Visualisierungsstils auf "Flat Style" gefühlt etwas mehr. Zwischen der Eingabe und dem anzeigen des neuen Wert liegen aber immernoch ca. 2 Sekunden, also nicht akzeptabel.
Welchen Parameter beeinflussen die Geschwindigkeit der Webvisu noch?


----------



## KLM (4 Januar 2022)

Viel macht es aus, wie die Visu selbst erstellt ist. Dazu findest Du im der Dokumentation ein PDF, hier im Forum einige Threads und eine Internetsuchmaschine hilft sicherlich auch. Für einen eigenen Kommentar müsste ich Deinen Aufbau sehen, sonst wird das hier zu viel.
Interessant finde ich Deine Formulierung, dass 16 Clients per Direktlink zugreifen. Wie ist das umgesetzt?


----------



## andreas-w211 (5 Januar 2022)

in Ermangelung von Erfahrung habe ich einfach 16 einzelne Seiten erstellt. Im Visualisierungsmanager habe ich 16 Aufrufe, als Startvisualisierung den Namen der jeweiligen Visu eingetragen, unter "Name der .htm-Datei" ebenfalls eine Bezeichnung von 01 bis 16. Die Panel (Raspi mit Touch) starten im Kiosk- Mode und rufen als Startseite die entsprechende Seite auf (ip/webvisu/01.htm))


----------



## KLM (6 Januar 2022)

Mir fehlt leider die Erfahrung hinsichtlich Performance bei so vielen Startseiten. Aus dem Bauch heraus würde ich sagen, dass das kein Problem ist. Ändert ich denn das Verhalten, wenn Du ein paar Zugriffe der Panels entfernst (physisch abstecken oder ausschalten und etwas warten bis die Clients auf dem Server terminiert sind)?


----------



## andreas-w211 (6 Januar 2022)

Wenn ich ein Panel direkt an den PLC stecke (ohne Switch + die anderen 15 Panels) reagiert die Visu mit einer minimalen Verzögerung, mit der man leben kann. Wenn ich den Switch + 6 weitere Panels anschließe wird die Reaktion schon langsamer, bei über 12 Panels wird es sehr langsam. Es spielt anscheinend keine Rolle ob die Panels aktiv sind (bedient werden) oder sich im Ruhemodus befinden.
Ich hatte mit der Codesys V2.3 (Visu mit Java) Visualisierungen erstellt mit wesentlich mehr Inhalt, eine Verzögerung bei Anzeige oder Bedienung konnte ich hier nicht feststellen. Ist die Verzögerung HTML5- bedingt?


----------



## KLM (6 Januar 2022)

Einfach weil es recht schnell gemacht ist und mir Erfahrungswerte fehlen, würde ich die Startseiten auf nur eine reduzieren und testen und schauen, ob sich das Verhalten ändert. Also nur eine Startseite auf die alle Clients schauen. Sollte sich das Verhalten normalisieren, brauchst Du eine andere Methode für die Deeplinks, falls nicht würde ich mal einen Blick auf Dein Projekt werfen, wendest Du Dich an den Support oder wir finden jemand anderen, der eine Idee hat.


----------



## andreas-w211 (24 Januar 2022)

Das umstellen auf eine Startseite, auf die alle Clients schauen, kann ich leider nicht so einfach umsetzen. 
@WAGO: was sagt ihr zu dem Delay bei mehreren Startseiten? Ist das prinzipbedingt oder sollte das Problem nicht auftreten?

Andreas


----------



## ClMak (24 Januar 2022)

Ich habe leider keine Lösung für dich aber eine Einschätzung zu deiner Problematik.
Der Zugriff auf den PLC Web-Server über mehrere Clients ist konzeptionell ein Fehler. Die Performance der PLC ist nicht ausreichend, um mehrere Clients parallel zu bedienen. Bei 15 Panels wirst du nach meiner Einschätzung nie mit einer vernünftigen Reaktionszeit rechnen können - egal was du machst. Bei 2-3 Panels wird das vielleicht noch so einigermaßen funktionieren...


----------



## andreas-w211 (24 Januar 2022)

Heisst das, dass mehr wie 2 oder 3 Panels nicht sinnvoll per Webvisu zu betreiben sind? Oder gibt es dazu ein anderes Konzept?


----------



## holgermaik (26 Januar 2022)

> Die Performance der PLC ist nicht ausreichend, um mehrere Clients parallel zu bedienen.


Das kann ich so nicht bestätigen. Ich habe zwar noch keine Anlage mit 15 Webvisu gemacht aber mit bereits 6. Dabei ist keine merkbare Verzögerung der Eingabe aufgetreten.
Natürlich darf der PFC nicht bis unters Dach ausgelastet sein.
Ich denke das Problem liegt in der Programmierung des Programms und der Visu und an der eventuellen Installation von Zusatzsoftware.


----------



## andreas-w211 (26 Januar 2022)

Der PFC ist mit ca. 16 - 20% CPU- Auslastung wohl nicht am Ende. Zusatzsoftware habe ich nicht installiert. 
Programmierung: sehr simpel, Tempersoll- und Istwerte werden verglichen, und Ausgänge geschaltet (simpler Temperaturschalter). Die Sollwerte werden über Slider durch die Visu / Panel vorgegeben. Die 16 Visus (je Nutzungseinheit eine Visu/Panel) beinhalten nur jeweils 4 Slider und die Anzeige der Soll- und Isttemperatur.
Bei einer Überlastung oder unsauberen Programmierung würde ich zumindest eine deutlich höhere CPU- Last erwarten.


----------



## KLM (7 Februar 2022)

Bei Deinem Fokus auf die CPU-Auslastung (ich gehe vom Gesamtsystem via htop oder top aus), gehst Du davon aus, das der Webserver unbegrenzt freie Systemressourcen (CPU und RAM) verwenden kann. Kenne die Implementierung des Webservers zwar nicht im Detail, aber der ist ganz bestimmt begrenzt. Und: htop und top sind nicht echtzeitfähig, liefern also nur eine grobe Richtung auf dem Linux mit Echtzeiterweiterung. Besser, aber auch nicht echtzeitfähig, wäre daher die Betrachtung der mittleren Last (1, 5, 15 Minuten).


----------



## andreas-w211 (8 Februar 2022)

Ich habe keine Doku von Wago zur Webvisu gefunden, die mich wirklich weiterbringt. Habe ich eine Doku, speziell zur Webvisu übersehen oder wo kann ich noch Infos bekommen?


----------



## KLM (8 Februar 2022)

Das Handbuch zur Visu liegt im doch gleichen Verzeichnis, wie das zu e!C selbst. Du suchst aber eher was zur Implementierung, also eher auf der Github Seite von WAGO.


----------

