Hinweis: Ich bin mir nicht sicher, ob dies ein Fehler in Discourse ist. Ich habe versucht, die notwendigen Beweise zu sammeln, und bisher habe ich nichts gefunden, das auf unsere Infrastruktur/Setup hindeutet. Unsere Konfiguration ist bei Tappara.co so vanilla wie möglich.
Beobachtetes Phänomen:
Chat-ähnliche schnelle Diskussionstopics hören auf, sich automatisch zu aktualisieren. Nach einer Verzögerung von 30 bis 180 Sekunden setzt die Aktualisierung normalerweise fort und zeigt die Beiträge, die während des Einfrierens erstellt wurden.
Was wir bisher wissen
Wir haben dies in der vorherigen Saison nicht gesehen; das letzte Spiel wurde im März gespielt.
Wir betreiben den stabilen Zweig und haben das letzte große Update im August durchgeführt.
Das Problem wurde sofort bei den ersten Ausstellungsspielen gemeldet, bei moderatem Verkehr/Aktivität.
Dies betrifft iOS und Android Chrome, ist aber auf Chromebooks weitaus seltener.
Während ich dies schreibe, sehe ich Einfrieren auf meinem Android-Telefon, während die Diskussion auf meinem Chromebook wie erwartet verläuft. Zwei verschiedene Geräte im selben Netzwerk.
Die Erfahrung variiert je nach Benutzer/Client. Unterschiedliche Benutzer melden die Einfrierungen zu unterschiedlichen Zeiten. Insgesamt haben wir in etwa 30 Minuten rund 300 Nachrichten aufgezeichnet, und Benutzer meldeten Dutzende von Einfrierungen. Meist scheinen die Einfrierungen mit Ereignissen im Spiel (Tore, Strafen) korreliert zu sein.
Dinge, die ich versucht habe, auszuschließen
CloudFlare – wir haben ein Spiel ohne CF-Caching durchgeführt, und das Problem bestand weiterhin.
CPU-Überlastung – die CPU-Auslastung liegt weit innerhalb der Grenzen, normalerweise bei etwa 20–30 %.
Festplattenvollständigkeit – die Festplatten-I/O scheint weit innerhalb der Grenzen zu liegen. Wir verwenden UpClouds MaxIOPS-SSDs.
Weitere Informationen
Ich hatte den Chrome-Inspektor während des Spiels laufen, und einige 429er wurden aufgezeichnet, aber für mich korrelierten sie nicht mit dem Einfrieren.
Die Endbenutzer erhalten keine Benachrichtigungen bezüglich 429er (Verlangsamung) oder extremer Last. Die Aktualisierung friert einfach ein und setzt dann einfach fort. Hat sich der Rate-Limiter kürzlich geändert? Ich habe den Eindruck, dass Ratenbegrenzungen eine Benachrichtigung in der UI auslösen sollten?
Ein wirklich lästiges Problem, das die Spiel-für-Spiel-Spiel-Chats wirklich beeinträchtigt. Wir betreiben diese seit Jahren, und ich habe so etwas noch nie gesehen.
Wenn Ihre Web-Worker von Anfragen überlastet werden, führen wir Verzögerungen in der persistenten Verbindung ein, die das Thema automatisch aktualisiert, wenn neue Beiträge eintreffen.
Wenn Sie dies sehen und die CPU-Auslastung wie gemeldet niedrig ist, erhöhen Sie bitte die Anzahl der Unicorn-Worker. Das sollte dieses Problem beheben.
Wir haben bereits 11 Unicorns auf einem 6-Kern-VPS erreicht. Wie erwähnt, ist dies in der vorherigen Saison, die im März endete, nie aufgetreten. Jetzt tritt es sogar bei moderatem Verkehr auf. Außerdem passiert dies auf mobilen Geräten, insbesondere Android Chrome, viel häufiger als auf Desktops.
Außerdem konnten wir unsere CPU bereits vorher erschöpfen (zum Handelsfristende).
Ich habe ein Spiel übersehen, das ich überwacht und den Server herumprobiert habe. Wir haben die web.ratelimited-Parameter verdoppelt, aber das hat das Problem nicht gelöst.
Inspector fängt eine Reihe von 429ern ab:
1. Anfrage-URL:
https://tappara.co/message-bus/3ed86765a67f4c31ba4053a0352ecaf5/poll
2. Anfrage-Methode:
POST
3. Statuscode:
429
Nächstes Spiel morgen, also kann ich die Unicorns ausprobieren. Wie hoch können wir gehen? Hat sich das mit dem neuesten großen Update geändert?
Edit:
Ich habe mir die Statistiken angesehen, und unsere Aktivität war bisher geringer als im Frühjahr (Seitenaufrufe, Benutzer). Die Anzahl der Beiträge pro Spiel-Chat ist identisch (etwa 900–1000 pro 3 Stunden).
Aus einem unbekannten Grund sind wir derzeit also nicht in der Lage, dasselbe Publikum zu bedienen, das wir im März hatten.
Super! Könntest du bitte bestätigen, ob es in den letzten sechs Monaten eine Änderung oder einen Rückgang gab, der dies verursacht hat?
In der Zwischenzeit werde ich für das heutige Spiel die Einhörner etwas mehr aufpumpen und schauen, was passiert. Falls wir auf irgendeine Weise unterstützen können, lass es mich einfach wissen.
@falco Die Anzahl der Einhörner ist definitiv nicht der entscheidende Faktor. Ich habe sie für das heutige Spiel auf 15 erhöht. Das Spielthema war ruhig, es wurden nur 700 Nachrichten gesendet, aber es traten ständige Einfrieren auf. Die CPU-Auslastung war moderat und lag zwischen 5 und 25 %.
Je mehr ich dies untersuche, desto wahrscheinlicher scheint es, dass es sich um ein Problem und eine Regression handelt, aber meine Fähigkeiten reichen nicht aus, um die Ursache zu identifizieren.
Ich glaube, es gibt einen Fehler im Client, bei dem er im Wesentlichen nach einem einzigen Fehler keine Updates mehr durchführt. Meine Vermutung ist, dass dies daran liegt, dass Ihre Benutzer ein Rate Limit erreicht haben.
Ich werde diese Woche untersuchen, wie der Client robuster gemacht werden kann. Wie ich bereits sagte, ist dies heikler Code und wird Zeit in Anspruch nehmen.
Die Fehlersuche bei diesem Problem hat mich dazu gebracht, über die UX von fast Echtzeit-Diskussionen im Allgemeinen nachzudenken. Viele Communities befassen sich mit Ereignissen im echten Leben, die die Diskussion naturgemäß in Richtung eines chat-artigen, schnellen Gesprächs „drängen
Ich finde die Idee gut, aber es bräuchte eine Art Umgehung des Shadow-Bannings, damit Nutzer ihre eigenen Beiträge sofort sehen. Andernfalls könnten sie doppelt oder sogar dreifach posten, weil sie denken, das Forum funktioniert nicht.
Dadurch stellen wir sicher, dass ein Server nicht überlastet wird, wenn 1000 Personen ein Thema betrachten und gleichzeitig Beiträge erstellt werden.
Der Client verhält sich in diesen Fällen nun deutlich sauberer.
In Bezug auf @ljpps Frage hier: Ich bin noch unentschlossen, ob ich dies zurückportieren soll, da dies API-Änderungen mit sich bringt und eine ziemlich große Änderung ist. Falls wir es zurückportieren … wird es wahrscheinlich einige Wochen dauern. Ich muss dies unter Last in der Produktion beobachten, und da wir so viel Spielraum bei unserem Hosting haben, treten derartige Ereignisse so selten auf, dass es eine Weile dauern wird, bis wir eines davon erfassen.
Erwarte eines bis Ende des Jahres… also würde ich nicht damit rechnen, dass es sehr bald kommt. Wir werden jedoch diese Woche eine weitere Beta-Version veröffentlichen!
Alle unsere Hosting-Dienste laufen auf der Beta… also ja, aber wir haben riesige Kapazitäten.
Ich verstehe die Überlegungen, warum dies möglicherweise kein Kandidat für ein Backport ist. Ich habe unseren Ratelimiter gerade deaktiviert, und morgen ist das nächste Spiel. So werden wir einen groben Eindruck davon bekommen, ob er als praktikable Workaround-Lösung für Instanzen dient, die nicht bereit sind, in den Beta-Zweig zu wechseln.
Wir erwägen definitiv, in den nächsten Monaten auf den Beta-Zweig umzusteigen. Allerdings gibt es auch noch andere Bedenken – @rizka hat darauf hingewiesen, dass die FI-Übersetzung hinterherhinkt (er könnte sich jedoch später in dieser Woche darum kümmern).
Leider hat das Deaktivieren des Ratelimiters überhaupt nicht geholfen. Es war ein langweiliges Spiel, und 83 Nutzer haben nur 580 Nachrichten verfasst. Während des Spiels wurden mehrere Einfrieren gemeldet.
Gibt es potenzielle Hacks oder Workarounds, die wir ausprobieren können, während wir auf das Upgrade auf eine Edge-Version warten?
Die ‘Freezes’ sind ein Client-Bug; das Programm reagierte einfach nicht richtig auf Fehlerbedingungen. Schon ein einziger Rate-Limit-Fehler und auf Stable bist du erledigt.
Mir fällt keine Workaround-Möglichkeit ein, außer auf die Beta-Version zu aktualisieren (wir bringen morgen eine neue heraus).
Eines unserer entwicklungsorientierten Mitglieder hat vorgeschlagen, die folgende Variable anzupassen. Was haltet ihr davon – seht ihr das als potenzielle Workaround-Lösung?
Dies hat die Anzahl der beobachteten Verlangsamungen erheblich reduziert, das Problem jedoch nicht vollständig gelöst. Die CPU-Auslastung stieg während großer Ereignisse im Spiel auf etwa 55 % an.
Das bezweifle ich… Das Problem bei hoher Antwortlast war, dass wir vor dem neuen Design eine Flut von Anfragen auslösen konnten, die die Ratenbegrenzungen durch max_reqs_per_ip_per_10_seconds und Ähnliches ausgelöst hätten. Um diese Last zu bewältigen, wären enorme Ressourcen erforderlich.
Stellen Sie sich folgendes vor:
30 Nutzer posten innerhalb von 10 Sekunden eine Antwort.
100 Personen schauen sich das Thema an.
Der Server muss in der Lage sein, 3000 GET-Anfragen zu bearbeiten, um jeweils nur eine einzelne Antwort abzurufen.
Wenn IRGENDEINE dieser Anfragen aus irgendeinem Grund fehlschlägt, friert die Benutzeroberfläche ein und erscheint defekt.
Das neue Design löst dieses Problem sehr sauber: Die Last wird kontrolliert abgebaut, Anfragen werden gebündelt, falls ein Rückstau entsteht, die Benutzeroberfläche friert nicht ein und so weiter.
Ich kann mir nicht vorstellen, dass das alte Design mit 100 gleichzeitigen Nutzern und 30 Antworten innerhalb von 10 Sekunden skalieren könnte.
Ich kann mir hingegen gut vorstellen, dass das aktuelle überarbeitete Design problemlos mit 1000 gleichzeitigen Nutzern funktioniert, die ein Thema mit 30 Antworten innerhalb von 10 Sekunden betrachten.
.