Vielen Dank. Wahrscheinlich haben Sie mir damit viele Stunden an Fehlersuche, Probieren und Irrwegen erspart.
Dieser Unterschied im Verhalten hat mich zu dem Schluss geführt, dass es sich um eine anwendungsbezogene Korrelation handelt, die von einem Frontend-Problem herrührt, das die App „zum Absturz bringt
[quote=“Iceman, Beitrag: 46, Thema: 144277”]
Als Anmerkung: Dieses Verhalten tritt auch bei Plugins wie Babel auf. Allerdings scheint das Babel-Plugin deutlich mehr „gleichzeitige
[quote=“ljpp, Beitrag: 47, Thema: 144277”]
Was mich dazu brachte, das Backend zu verdächtigen, ist die Tatsache, dass wir diese Spiele-Chats seit Jahren betreiben und dieses „Ersticken
Großartige Nachricht, dass Sie das im Blick haben. Können Sie bestätigen, ob sich das seit letztem Frühling verschlechtert hat?
Unsere lokale Hockeyliga versucht, die Spiele am 1. Oktober zu starten. Das bedeutet, dass unsere Website wöchentliche Live-Traffic-Spitzen liefern kann, falls Sie das Verhalten in einer echten (nicht simulierten) Umgebung untersuchen möchten oder müssen.
Schreiben Sie mir eine Direktnachricht, falls Sie interessiert sind. Wir unterstützen Sie gerne.
Aus UX-Sicht sollte der Endnutzer auf irgendeine Weise wissen, dass eine Diskussion aktiv ist, selbst wenn das System zu kämpfen beginnt. Dies könnte unnötige Browser-Aktualisierungen verhindern.
Nein, das kann ich leider nicht bestätigen. Das war schon immer so.
Das erste Spiel ist gerade zu Ende gegangen, und wir haben definitiv ein Problem, das wir im März nicht hatten. Der Grund ist noch unbekannt.
Der Spiel-Chat friert auf der Frontend-Seite ein, obwohl die Serverauslastung weit unter 100 % liegen sollte.
Einige unserer Nutzer haben während der Einfrierphasen eine Reihe von 429-Serverantworten festgestellt, aber ich kann nicht sagen, ob dies „normal
Ich habe eine davon gesehen, während ich eine völlig irrelevante ‘500’-Antwort untersuchte 
Der Server war überhaupt nicht ausgelastet, aber ich habe mit einer Frontend-Nginx-Konfiguration (http2) herumgespielt.
Meinst du mit „Spiel-Chat
Stimmt. Innerhalb weniger Stunden gab es rund 900 reaktionäre Antworten. @ljpp hat genauere Zahlen zu den Nutzern, aber wir sprechen von hunderten Nutzern, die während des Spiels zu jedem Zeitpunkt das Thema durchsucht haben.
Seltsamerweise betrifft dies nicht jeden Nutzer. Ich beispielsweise habe auf keinem Gerät Probleme festgestellt. Aber den Berichten zufolge ist es weit verbreitet genug.
Es ist nicht so offensichtlich zu erkennen, besonders wenn man nicht genau hinschaut.
Zunächst gibt es eine Pause von 30–60 Sekunden ohne Antworten. Nichts scheint „falsch
Ich stimme @pfaffmans Beitrag dazu zu.
Versuchst du nicht, einen Chat-Anwendungsfall auf eine Forenplattform zu zwingen?
Warum integrierst du nicht stattdessen einen Chatdienst wie Mattermost oder Discord in die Benutzeroberfläche deiner Discourse-Seite und lässt dieses Medium für in-game-Diskussionen nutzen?
Du könntest eine andere Möglichkeit finden, das Spiel in einem Foren-Topic zu behandeln, etwa für Vor- oder Nachbesprechungen, wo die Auslastung weniger hoch ist, aber vielleicht nützliche Zusammenfassungsinformationen enthalten sind, die viele Benutzer später wieder abrufen möchten.
Ich sehe auch keinen Vorteil darin, eine riesige Menge an spontanem Chat in einem Forum zu speichern. Wird das jemand nochmal lesen? Ist es nützlich?
Nun, er verwendet dafür das Wort „Chat“, aber sein Discourse-Setup kann laut dem Benutzer „972 Beiträge innerhalb von ca. 3 Stunden“ in einem Thema nicht bewältigen … meiner Meinung nach sollte es das können. Selbst ein einfaches phpBB könnte in 3 Stunden ein Vielfaches davon bewältigen.
Also ein Post alle 10 Sekunden? Für sich genommen klingt das nicht unvernünftig. Aber dann machst du das Thema auf 1000 Posts lang, haben mehrere hundert Nutzer teilgenommen und dazu kommen noch Spitzen bei den Posts. Ich kann die Herausforderung verstehen!
Aber was ist hier eigentlich die wahre Ursache/der Flaschenhals? Ist es die Anzahl der teilnehmenden Nutzer, ein Post alle 10 Sekunden, das Rendern geänderter Inhalte für (zu) viele anonyme/nicht-anonyme Nutzer oder die Anzahl der Verbindungen, die erforderlich sind, um zu viele angemeldete Nutzer zu bedienen?
Wird er das gleiche Problem haben, wenn nur 2 Nutzer im selben Zeitraum die gleiche Anzahl von Posts in einem Thema veröffentlichen?
Selbst bei nur 972 angemeldeten Nutzern, die jeweils einen einzigen Post in diesem Thema verfassen, kann Discourse das nicht bewältigen? Und wenn ja, warum? Ist Discourse wirklich nur die richtige Wahl für sehr kleine Communities mit einer geringen Anzahl gleichzeitiger angemeldeter Nutzer?
Ich frage mich das, da wir zeitweise bereits bis zu 400 gleichzeitige angemeldete Nutzer haben, die bis zu 3000 Posts pro Tag verfassen – bisher gab es keine Probleme.
Sie müssen eindeutig die Server-Spezifikationen und die Anzahl der laufenden Unicorns berücksichtigen, sonst sind die Ergebnisse dieses Stresstests weniger aussagekräftig.
Blenderartists (@bartv) hat meiner Meinung nach einen 64-GB-Server und etwa ein Dutzend Unicorns im Einsatz? Ein echtes Ungetüm 
Absolut, wir nutzen aktuell bei DigitalOcean nur 8 GB RAM und 4 vCPUs und haben derzeit keine Probleme. Wenn die Lösung also einfach darin besteht, mehr Ressourcen (RAM und CPU) hinzuzufügen, bin ich einverstanden. Seit dem Relaunch mit Discourse hatten wir an der Spitze etwa 2000 gleichzeitige Besucher auf einem viralen Beitrag; die Last lag knapp über 1, und die CPU-Auslastung betrug 60–70 %. Im Durchschnitt liegt die CPU-Auslastung bei ca. 15–20 %, wenn etwa 200–250 Benutzer gleichzeitig angemeldet sind.
Richtig Wir teilen gerne Daten, obwohl wir unser Discourse nicht als Chat nutzen und solche Spitzen nie erleben.
Man könnte das argumentieren, aber ich habe die Idee, Gespräche auf zwei Plattformen zu fragmentieren, wirklich nicht gerne. Echtzeitfähigkeit ist tatsächlich eines der Killer-Features von Discourse, das die Endnutzer schätzen. Unsere Spielzeit-Gespräche sind ein großer Erfolg und ein wichtiger Teil der Community-Kultur.
Beachte, dass wir diese Spiele seit vier Jahren durchführen und dies ein neues Problem ist, dem wir uns stellen. Hunderte von Spielen sind bisher reibungslos verlaufen, ohne etwas zu „erzwingen".
Eines unserer gebildeten Mitglieder hatte eine Theorie – könnten wir die globalen Grenzen von Discourse erreichen und hat vielleicht CloudFlare einen Einfluss?
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: Anzahl der Anfragen pro IP pro Minute (Standard ist 200)
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: Anzahl der Anfragen pro IP pro 10 Sekunden (Standard ist 50)
Das nächste Spiel ist in einer Stunde, und wir werden es mit deaktiviertem CF-Cache versuchen.
Beachte, dass wir CloudFlare ebenfalls seit 4 Jahren nutzen, obwohl es hier im Allgemeinen nicht empfohlen wird. Es gab nur ein oder zwei Probleme auf dem Weg, Brotli war eines davon und ein nicht aktualisierter Vorlage ein weiteres.
Nein, CF ist nicht die Ursache. Das Problem tritt auch mit deaktiviertem Cache auf. Es wurden 429er-Fehler gemeldet.
Ideen, jemand?
Ja, ich verstehe dein Bedenken hier. Ich würde nicht gerne wertvolle Erkenntnisse, die in Chats verloren gehen könnten, vermissen. Es ist ein kniffliges Dilemma.