Gestern haben wir eine große Leistungsverbesserung für Seiten mit aktiven Beiträgen und vielen Nutzern eingeführt. Das sollte auf Ihrer Seite sehr hilfreich sein.
Sehr gut, wir werden uns das ansehen und es eventuell testen.
Nun, jedes Spiel ist ein Einzelfall. Angesichts der aktuellen COVID-Situation (leere Arena) und des nahezu zufälligen Spielplans ist das Verhalten des Publikums kaum vorhersehbar oder mit historischen Daten vergleichbar.
Basierend auf diesem einzelnen Spiel kann ich nicht sagen, dass diese Änderung uns eine signifikante Verbesserung gebracht hat.
Die erste Periode war ruhig und verlief gut, doch die Ereignisse während der zweiten Periode führten zu einem Anstieg der Nachrichten und einer Zunahme der stillen Beobachter (Lurker). Etwa 60 % unserer Nutzer gaben an, Einfrieren erlebt zu haben.
Im Zwei-Server-Setup meldet nur der web_only-Server eine hohe CPU-Auslastung und einen hohen Lastdurchschnitt.
Der Modus „extreme load / read-only
Fortschrittsbericht aus den privaten Gesprächen: Die Erfahrung wurde verbessert, indem DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS auf 4 gesetzt wurde, und wir planen einige Kernänderungen, um das Ratenbegrenzungsverhalten des Message Bus zu verbessern.
Da wir einige Ähnlichkeiten mit der Situation von @ljpp feststellen, wenn auch in deutlich geringerem Ausmaß (fast ausschließlich in einem Zeitraum von etwa 5 Minuten um die Zeit, in der die Spiele enden), würde ich gerne wissen, ob es Anpassungen gibt, die man an der Schwelle vornehmen kann, bei der die Meldung über hohe Last ausgelöst wird und Benutzer aus dem Thema „herausgeworfen
Bitte klären Sie: Haben Sie Einfrierprobleme (das Thema wird bei neuen Beiträgen nicht aktualisiert) oder erhalten Sie Fehlermeldungen zu extremer Last?
In diesem Thread gibt es Anpassungen, die das Einfrieren etwas verbessern, aber sie erhöhen auch die Systemlast, sodass Sie eher mit Szenarien extremer Last konfrontiert werden.
In den von mir gemeldeten Situationen erleben wir manchmal ein Einfrieren von Themen. Tritt dies jedoch auf, zeigt das System gleichzeitig Warnungen über extreme Last an. Daher kann ich nicht sagen, was genau das Problem ist.
Extreme Last ist für uns kein Problem, solange sie niemanden aus Themen wirft oder Updates für neue Beiträge unterbricht. In diesem Fall würden wir es sogar bevorzugen, wenn das Laden langsamer erfolgt (das Lade-Rad könnte sich 15 Sekunden lang pro Benutzer drehen, um Beiträge zu lesen oder zu veröffentlichen), anstatt dass das System einfriert oder Benutzer herausgeworfen werden.
Ich muss zustimmen. Die UX bei extremer Last ist für den Endbenutzer verwirrend.
- Wie viele gleichzeitige Benutzer haben Sie?
- Welche Art von Hardware?
- Link zu Ihren Forum-Statistiken?
Da wir jetzt auf der CDCK SaaS-Plattform sind, kann ich dies nur aus UX-Sicht beobachten.
In den letzten Wochen gab es in den Spielen einige heiße Phasen. Die „Einfrieren
Wir leiden ebenfalls darunter.
Ein weiteres Problem: Beim Springen zum ersten ungelesenen Beitrag kann dieses Verhalten einige Male wiederholt werden (man landet mehrmals beim gleichen „ungelesenen Beitrag“, obwohl sich die Position des ersten ungelesenen Beitrags bei jedem Mal hätte ändern müssen).
Als Beispiel:
- Ich springe zum ersten ungelesenen Beitrag.
- Ich scroll durch und lese die 100 ungelesenen Beiträge.
- Dann gehe ich zu einem anderen Thema oder zur Startseite…
- Nach einer Minute oder so gibt es etwa 30 neue ungelesene Beiträge, aber wenn ich auf das Symbol klicke, werde ich erneut an die Position von Schritt 1 geworfen (also 130 Beiträge zurück und nicht nur die neuen 30 ungelesenen).
Aber, noch einmal: Dies passiert nur in sehr, sehr aktiven Themen, und zwar nur für einige Minuten während des absoluten Spitzenzeitpunkts, wenn alle Nutzer gleichzeitig im selben Thema aktualisieren und posten. Es ist etwas nervig, aber bisher kein Dealbreaker.
Das würde ich als Erfolg werten.
Könntest du hier auf Meta eine Reproduktion bereitstellen? Wahrscheinlich nicht, da dies eine große Anzahl aktiver Nutzer erfordert, die gleichzeitig im selben Thema inaktiv sind.
Meine aktuelle Überlegung ist, dass wir eine Live-Chat-Funktion entwickeln und diese Just-in-Time instanziieren sollten, wenn du …
-
viele Nutzer
-
im selben Thema
-
zur gleichen Zeit
hast. Erst dann und nur dann sollte ein Live-Chat-Overlay instanziiert werden, und die Nutzer sollten stark dazu gedrängt werden, dies anstelle von Antworten zu nutzen. Vielleicht sollte man sogar die Möglichkeit deaktivieren, auf das Thema zu antworten, mit:
Hey, anscheinend wolltest du eigentlich einen Chatraum .. hier ist er, viel Spaß! 
Ja, ich weiß, was du meinst, aber es ist auf diese Anlässe so beschränkt, dass ich denke, es lohnt sich den Aufwand nicht. Wir haben normalerweise solche Matches ein- bis zweimal pro Woche, und zwar meist in der 5-Minuten-Phase, sobald das Match zu Ende ist. Aber ich habe tatsächlich mehrmals darüber nachgedacht (es wäre schön, eine temporäre Chatraum-Funktion oder einen Umschalter für die 90-Minuten-Spieldauer eines Fußballspiels zu haben). 
Trotzdem werde ich eines Tages versuchen, es zu reproduzieren, indem ich eine Weile den Bildschirm aufnehme.
Unsere Instanz zeigt seit Beginn der Playoff-Spiele einige 429-Fehler an. @staff sollte in den letzten 3,5 Stunden unserer Logs einige davon sehen können, und es werden weitere erwartet, sobald das entscheidende Tor fällt (das Spiel geht gerade in die zweite Verlängerung, während ich dies schreibe).
In jedem Fall: Falls ihr dies noch protokolliert und nachverfolgt, bleiben nicht viele Gelegenheiten mehr, da die Finalspiele und die anschließende Vorsaison immer näher rücken.
Ich wollte nur meinen Namen hier im Thread hinzufügen, um dem Verlauf folgen zu können. Wir sind ein neues Forum für Turnen. Wir haben gestern Abend während der US-Olympia-Qualifikation genau das oben Genannte sowie ein „Einfrieren
Wenn du Hunderte von Benutzern in einem einzigen Thema hast und Discourse als Chat nutzt und es sich um ein zeitlich begrenztes Event handelt, würde ich empfehlen, den Server vorübergehend etwas zu verstärken.
Der größere Premium-AMD-Droplet bei Digital Ocean für die 16 Tage der Olympischen Spiele kostet 54,85 $ und sollte für eine Community deiner Größe mehr als ausreichend sein.
Diese Zeilen fehlen in meiner app.yml. Soll ich sie einfach hinzufügen?
Ja. Fügen Sie sie im Abschnitt env hinzu.
Falls dies noch im Blickfeld des Personals ist, startet unser Launch heute Abend um 18:30 Uhr (UTC+3) und morgen erneut zur gleichen Zeit.
Nach zwei durch COVID zunichte gemachten Saisons herrscht große Vorfreude, daher erwarte ich starke Traffic-Spitzen auf tappara.co.
@ljpp
Wie ist deine aktuelle Situation? Hat Redis 6 dir geholfen?
Wir nutzen jetzt CDCK SaaS, weshalb wir das Team vorab informiert haben. Wir sind in dieser Hinsicht gewissermaßen eine Testumgebung.