wir betreiben aktuell einen Alarmiator Server mit folgenden Eckdaten:
Netcup V-Server (4 CPU, 4 GB RAM, SSD)
Docker
240 Mitglieder (Tendenz steigend) in
11 Organisationen mit insgesamt
35 Gruppen
Nachdem wir beim Probealarm (geht dann wirklich an alle Mitglieder) das Problem haben, dass die APP in diesem Fall ca. 2 Minuten keine Rückmeldung anzeigt, bzw. auf die Eingabe der Rückmeldung nicht reagiert, ist uns aufgefallen, dass alle CPUs auf dem Server auf fast 100% laufen.
Sobald die Serverlast wieder „normal“ ist geht alles wie gewohnt.
Weiterhin laufen laut top 11x die gleichen Prozesse.
Gehört das so oder hab ich irgendwo was falsch konfiguriert? Kommen die 11 Prozesse von den 11 Organisationen?
Welche Möglichkeiten haben wir, um das Verhalten in den Griff zu bekommen? Sicherlich ist das ein extrem Fall - aber wir hätten gerne dass auch hier alles „flutscht“, zumal ja einige das wohl auch auf einem Pi laufen haben
Das sind mehrere Thread eines Prozesses. Also hast du nichts falsch gemacht. Ich nutze gerne „htop“ da kannst du mit „Shift“ + „H“ umschalten zwischen „Thread View“ und „Prozess View“. Wenn du umschaltest siehst du, dass tatsächlich nicht 11 Prozesse laufen.
Zum eigentlichen Problem:
Wir haben mehrere Instanzen die wir betreiben. Zwei davon haben aktuell jeweils 270 Mitglieder mit Probealarm für alle Mitglieder mit mehreren Orgas und Gruppen. Diese haben allerdings ein paar mehr CPU Cores und deswegen läuft es dort wohl ohne Probleme und ist uns so nicht direkt aufgefallen.
Wir sind heute auf Suche gegangen und haben eine Vermutung woran es liegen könnte. Man hat hier natürlich die Schwierigkeit, dass ein Alarm mit vielen Usern eine viel höhere Last in kurzer Zeit als beim Normalbetrieb darstellt.
Deswegen arbeiten wir seit heute schon daran das so umzubauen, dass gerade das Rückmeldungen geben performanter wird und es so hoffentlich sehr bald bei dir ordentlich „flutscht“.
Ein wenig musst du dich also leider noch gedulden aber ich hoffe du bist erstmal beruhigt, dass du nichts falsch konfiguriert hast und es wirklich nur an der Spitzenlast liegt durch gute Nutzer, die schnell Rückmeldung geben.
Hallo,
noch ein Gedanke dazu: Aus Anwendersicht ist es in dieser „heißen“ Phase ungünstig, dass das Verhalten der App suggeriert, man habe keine Rückmeldung gegeben (weil die Buttons Ihre ursprüngliche Farbe behalten). Das führt dazu, dass Anwender immer wieder auf die Buttons drücken. Ich vermute, dass dies auch weitere Rückmeldungen der App an den Server erzeugt und somit das Performance Thema noch verschlechtert.
Kann evtl. das UI der App angepasst werden um die erfolgte Rückmeldung anzuzeigen bevor diese vom Server bestätigt wurde? (Und ggf. nach einem Timeout bei fehlendem Commit wieder „entfärbt“ werden?)
Dann versuch ich das erstmal mit etwas mehr Leistung / CPUs kurzfristig zu erschlagen, Pressiert ja nicht wirklich, da das System ja sonst stabil läuft und wirklich nur am Probealarm auftritt
Weiter so! Wenn wir euch irgendwie unterstützen können - jederzeit gerne.
Ein kurzer Einwand von meiner Seite, wir würden eine solche Umsetzung in der App auch befürworten, da bereits des öfteren aufgrund schlechter Internetverbindung die Rückmeldung nicht durch ging.
Sei es wegen eines wechselnden Wlan-Netzwerkes innerhalb der Bewegung der Person oder schlechtem Mobilfunkempfang, viele versuchten dies durch mehrmaliges drücken der Auswahlmöglichkeiten, was sicherlich auch zu einem Anstieg der Datenverbindung führt und die Problematik weiter verschlimmbessert.
Eine sichtbare Funktion, sei es ein drehender Kreis wie in Windows beim Laden o.ä., bis eine Rückmeldung erfolgreich an den Server übergeben wurde und die anderen Felder dann erst grau hinterlegt werden wäre hierbei sicherlich von Vorteil.
