Mit diesen Einstellungen war die UX besser. Ja, es gab mehrere „Verstopfungen
Nur um andere Ursachen auszuschließen: Ich habe den Server auf 8 vCores und 32 GB RAM upgegradet. Ich habe die Datenbank-Puffer auf 16 GB und die Unicorn-Prozesse auf 16 gesetzt. Alle anderen Einstellungen sind wieder auf den Standard zurückgesetzt.
Leider hat das Upgrade nicht viel gebracht. Schnelle Diskussionen frieren ständig ein, selbst bei durchschnittlicher Aktivität.
Die Performance ist heutzutage miserabel. Ich vermute, ich muss mich jetzt mit Tools wie Prometheus beschäftigen. Ich bin zu 95 % sicher, dass die Performance der Software seit Version 2.3 erheblich zurückgegangen ist.
Bruder @Iceman hat im September weitgehend ignoriert worden. Er berichtet, dass die Staus unabhängig davon auftreten, welche Hardware er einsetzt?
Ich vermute, dass Sie an eine Redis-Engpass stoßen, aber wie ich bereits mehrfach erwähnt habe, können wir nur sicher sein, wenn Sie diese Statistiken sammeln. Ohne diese Daten ist es, als würden wir Astrologie betreiben.
Wenn mein Verdacht zutrifft, erklärt dies auch, warum das Hinzufügen weiterer langsamer Kerne und mehr RAM keine Verbesserung bringt. Da Redis single-threaded ist, können Sie nur durch leistungsstarke Kerne skalieren.
Wir werden bis Ende des Monats ein neues Image mit dem finalen Release von 2.6 veröffentlichen. Dieses enthält Redis 6 und neue app.yml-Variablen, um diese Vorteile optimal zu nutzen. Lassen Sie mich wissen, ob Sie das früher testen möchten – ich kann Ihnen entsprechende Anweisungen geben.
Mir ist das gerade in einem geschlossenen Thema aufgefallen. @codinghorror – das ist nicht korrekt. Was der Endnutzer in einer Hochlast-Situation tatsächlich erhält:
- Eine Benachrichtigung, dass er ausgeloggt wurde
- Er wird zur Indexseite der Seite weitergeleitet
- Die Indexseite zeigt die Banner-Benachrichtigung über die hohe Last
Der Nutzer ist jedoch nicht wirklich ausgeloggt. Normalerweise funktioniert die Seite ganz normal, wenn man auf das aktive Thema zurückkehrt.
Auch diesmal melden keine unserer Kunden (von Tausenden, und viele davon deutlich aktiver als Ihre Seite) dieses Verhalten. Eine weitere Diskussion ist daher im Grunde sinnlos – wir haben keine Einsicht in die seltsame Konfiguration oder die Hardware-Performance-Probleme, die Sie möglicherweise vor Ort haben.
Hoffentlich wird sich das in Zukunft ändern, und wir werden einen besseren Einblick in das tatsächliche Problem erhalten.
Ich habe lediglich gemeldet, wie die tatsächliche UI/UX bei hoher Last aussieht. Nichts weiter.
Das Verhalten sollte so sein, dass sie auf der Themenseite bleiben und eine abgemeldete Ansicht angezeigt wird, nicht auf die Startseite weitergeleitet werden.
Du hast höchstwahrscheinlich recht. Es ist Redis. Das neue Basis-Image verbessert die Situation, aber jetzt überschreiten wir die Kapazitäten der Server.
Möglicherweise, aber so funktioniert es in der Realität nicht. Ich habe es gerade vor einer Minute reproduziert.
Nun, zumindest dafür gibt es eine bekannte Lösung: 
Lösung: Code schlanker und effizienter gestalten 
Wenn Redis also der Flaschenhals ist, wie würdest du horizontal skalieren?
Es beschäftigt mich immer noch, was sich seit der letzten Saison geändert hat. Ich kann nicht viel organisches Wachstum oder eine Zunahme der Beliebtheit des Spielchats erkennen. Dennoch hat sich unsere Fähigkeit, den Betrieb aufrechtzuerhalten, dramatisch verschlechtert, und selbst in den ruhigsten Spielen kommt es zu Engpässen.
Solange du keine Metriken von deiner historischen Discourse-Instanz sammeln und diese mit den Metriken deiner aktuellen Installation vergleichen kannst, wobei die Hardware exakt gleich bleibt, wird dies ein Rätsel bleiben.
Der gesamte Unterschied könnte darin bestehen, dass dein VPS-Anbieter dich von einer physischen Maschine auf eine andere verlegt hat, dass du einen „lauten Nachbarn
Bitte spekuliert nicht darauf, das Problem beim VPS-Anbieter anzusprechen. UpCloud ist einer der besten Anbieter auf dem Markt und hat ihre Seite bereits auf Unregelmäßigkeiten überprüft. Sie werben auf unserer Website, und es wäre kein gutes PR, wenn die Seite ruckeln würde 
Es gibt jedoch keine historischen Daten, und um ehrlich zu sein, habe ich nicht so sehr darauf geachtet, da alles einfach funktionierte, bis im August die ersten Ausstellungsspiele stattfanden. Natürlich haben sich durch COVID die Verhaltensmuster der Menschen verändert, und wer weiß, was noch. In den Metriken unserer Website oder unseres Servers kann ich das jedoch nicht erkennen. 
Aber das ist hervorragendes Testmaterial. Ich habe @riking gerade einige Screenshots davon geschickt, was passiert, wenn die Serverüberlastung einsetzt. Ich schätze, bei euch sieht man das nicht so oft.
Beachte, dass dir niemand widerspricht – wir weisen nur darauf hin, dass ein Arzt bei der Diagnose eines Patienten nur begrenzt helfen kann, wenn er den Patienten lediglich über eine Videokamera im Internet sehen kann. 
Ich wollte nur sagen, dass dies genau so war, wie ich es erlebt habe, als ich meine Website zum ersten Mal eingerichtet habe (es ist also nicht einzigartig für Ihre Website).
Hier ist ein Thread, den ich damals dazu erstellt habe:
Dies war der Grund, warum ich zu den verschiedenen CPU-/Speicheroptionen springen musste, die hier beschrieben sind:
Leider hatte ich bisher keine Gelegenheit, wie beschrieben von Digital Ocean zu Hetzner zu wechseln (ich habe einen neuen Job angenommen). Das werde ich aber sobald wie möglich diesen Monat nachholen.
Das Erlebnis des Endbenutzers, entweder aus dem Thread geworfen zu werden oder im Thread zu bleiben (mit der Meldung „Abgemeldet“), schien von der Auslastung abhängig zu sein. (Mehr Benutzer wurden zur Indexseite der Website weitergeleitet, nachdem ein Tor erzielt wurde.)
Ich habe nicht genug technisches Wissen, um hilfreich zu sein, aber ich dachte, es könnte nützlich sein zu wissen, dass eine Sport-Website mit ähnlichen Spitzen im Chat-Verhalten zu einem ähnlichen Problem führt. Bei meiner (kleineren und jüngeren) Website wurde das Problem jedoch durch ein weiteres Upgrade des Servers behoben.
Wenn Sie Interesse daran haben, Daten zu haben, um Entscheidungen darüber zu treffen, wie man zukünftige Probleme diagnostiziert, können Sie das Prometheus-Exporter-Plugin für Discourse installieren.
Nur ein kurzer Update:
- Eine neue 2-Container-Umgebung auf 2 VPS-Servern installiert (web_only, data).
- Überraschenderweise (für mich) ist der web_only-Server stark ausgelastet, während die Datenlast relativ gering ist. Beide laufen auf einem UpCloud.com-Plan mit 4x vCore und 8 GB RAM.
- Der web_only-Server wurde auf einen UpCloud.com-Plan mit 6x vCore und 16 GB RAM upgegradet. Die Anzahl der Unicorns wurde auf 18 erhöht.
Trotzdem stoßen wir weiterhin auf verschiedene 429-Limiter. Der Modus „System unter hoher Last“ wurde jedoch nicht aktiviert.
Die Eishockeysaison wurde durch COVID ruiniert, und sie spielen nun einige zufällige Spiele ohne Publikum. Da wir Hosting-Guthaben bei UpCloud.com haben, nutzen wir unsere Möglichkeiten, um die Erfahrung zu verbessern. Aktuell laufen wir mit 6x vCore und 16 GB RAM für web_only sowie 4x vCore und 8 GB RAM für data, Unicorns bei 18.
Wir haben den Ratelimiter erneut deaktiviert…
DISCOURSE_MAX_REQS_PER_IP_MODE: none
…was hilft, aber wir erhalten weiterhin 429-Fehler von POLLs, die zu langen Verzögerungen oder Einfrieren für den Endbenutzer führen. Wir werden weiterhin optimieren, indem wir DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS erhöhen.
Bevor wir das tun, eine Frage an @sam / das Team:
Gibt es eine Umgebungsvariable, um den Schwellenwert für den extremen Lastmodus – Nur-Lese-Modus zu erhöhen, oder kann dieser vollständig deaktiviert werden?
Das sollte nicht notwendig sein. Wir würden uns freuen, Sie zu hosten, damit wir herausfinden können, warum dies trotz Ihres so geringen Datenverkehrs immer wieder ausgelöst wird.
Vielleicht, aber wir möchten den Server etwas weniger streng schützen, da die natürlich auftretenden Aktivitätsspitzen sehr kurz sind und sich im Allgemeinen innerhalb einer Minute oder so stabilisieren. Daher könnte eine leichte Erhöhung der Schwellenwerte die Benutzererfahrung verbessern, während wir auf den Umzug warten.
Die Spiele waren knapp (danke COVID), sodass wir sehr wenige Gelegenheiten hatten, dies zu messen und zu optimieren.
Wir haben festgestellt, dass selbst mit unseren verbesserten Hardware-Ressourcen (6+4 vCores und 16+8 GB RAM) bereits eine moderat aktive Nutzergruppe zu 429 Client-Freezes führen kann. Dies haben wir bei den U20-WM-Spielen beobachtet, die etwa 50 % unseres regulären Spielpublikums für die Chats angezogen haben.
Durch Messungen, Versuch und Irrtum haben wir uns für folgende Anpassungen entschieden:
DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.4
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: 400
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: 100Dies scheint 80 % der 429-Fehler zu eliminieren und ermöglicht so ein relativ reibungsloses Erlebnis für die meisten Nutzer.
Der nächste Schritt wäre gewesen, andere Hardware-Ressourcen zu kaufen – entweder dedizierte Server für Single-Thread-Geschwindigkeit oder einen Wechsel zu einem VPS-Anbieter, der Tarife mit unzähligen vCores anbietet. Für uns ist der nächste Schritt jedoch, mit dem Discourse-Hosting-Team zusammenzuarbeiten, wie @sam zuvor angedeutet hat.
Hoffentlich sind diese Anpassungen auch für @iceman, @alec oder andere hilfreich. Achten Sie unbedingt auf die CPU-Auslastung und Warteschlangen. Außerdem habe ich aus dieser Übung gelernt, dass 2 Container weit besser sind als einer – Anpassungen können mit nahezu null Ausfallzeit vorgenommen werden, und Hardware-Ressourcen können granularer genutzt werden.
Ich bin nach wie vor an neuen Anpassungen oder Erkenntnissen interessiert, die dazu beitragen könnten, die Performance und Benutzererfahrung bei schnellen Diskussionen, die durch reale Ereignisse angetrieben werden, zu verbessern.