„Aufgrund extrem hoher Last wird dies vorübergehend allen Nutzern so angezeigt, wie es auch angemeldete Nutzer sehen würden."
Ich betreibe eine Website mit Live-Diskussionen während Basketballspielen und hatte Probleme, dass der Server während der Spiele (Hauptaktivitätszeiten) überlastet wurde und diese Meldung anzeigte.
Gibt es eine Möglichkeit, die beste Lösung zur Behebung des Problems zu ermitteln? Liegt es an der Speicher-Geschwindigkeit, dem Arbeitsspeicher oder der CPU? Gibt es etwas, das ich tun kann, ohne meinen Server aufzurüsten? Oder wenn ich es doch tue – was sollte ich dann genau aufrüsten?
Dass weniger Leute das Forum nutzen? Noch besser wäre es, wenn sie ihre Nutzung verteilen würden, anstatt alle während des Spiels aktiv zu sein.
Aber das hilft alles nicht weiter. Da du weißt, wann die Spiele stattfinden, könntest du deinen Server nur während des Spiels aufrüsten oder während des Spiels mehrere Server hinter einem Load Balancer betreiben.
Du benötigst mehr und schnellere CPU-Kerne sowie mehr RAM, um die Anzahl der Web-Prozesse (Unicorn-Worker) erhöhen zu können und so Spitzenlasten im Verkehr bewältigen zu können.
Dies ist ein Bereich, an dem @sam aktiv arbeitet. Es scheint, dass neuere Versionen von Discourse in dieser Hinsicht leistungstechnisch Rückschritte gemacht haben.
Trotzdem ist die eigentliche Lösung, ein Live-Chat-Tool zu verwenden, wenn Sie Echtzeit-Interaktionen für Hunderte von Personen gleichzeitig benötigen – obwohl ich weiterhin in Frage stelle, wie und warum Chat „nützlich
Dieser Thread hier beschreibt das Problem ziemlich gut.
So war meine Erfahrung mit einem Fußballforum während eines Spiels, bevor die Probleme einsetzten:
Digital Ocean
1 CPU, 1 GB = 30–40 Nutzer in einer Chat-ähnlichen Situation
2 CPUs und 2 GB = 70–80 Nutzer in einer Chat-ähnlichen Situation
4 CPUs und 8 GB = gut für 120 Nutzer und 1000 Beiträge innerhalb von 2 Stunden. Das Limit wurde nicht erreicht.
Bei Hetzner (Spiegel-Site)
Meine Erfahrung:
3 CPUs (CPX 21 AMD-Chip) und 4 GB = Probleme bei 20 Nutzern
2 CPUs (Intel) und 8 GB = keine Probleme bei 20 Nutzern.
Ich bin nie dazu gekommen, es mit mehr Nutzern zu testen.
Der entscheidende Punkt ist, CPU und RAM zu verbessern. UND AUCH die Datei app.yml bearbeiten.
Fügen Sie hier mehr Unicrons hinzu und ändern Sie auch db_shared_buffers.
[quote=“codinghorror, Beitrag: 4, Thema: 180311”]
Das heißt, die eigentliche Lösung besteht darin, ein Live-Chat-Tool zu verwenden, wenn Sie Echtzeit-Interaktionen für Hunderte von Personen gleichzeitig benötigen – obwohl ich weiterhin hinterfrage, wie und warum Chat „nützlich
Ich verstehe, das ist etwas, das @sam, @eviltrout und ich genau im Auge haben. Die Situation, in der „hunderte von Nutzern gleichzeitig in dasselbe Thema eingeloggt sind und es durchsuchen“, taucht in letzter Zeit recht häufig auf, da Discourse immer beliebter wird.
Wir müssen möglicherweise ein neues Verhaltensmuster für diesen Fall einführen. Warnhinweise für den „schnellen Fahrstreifen“ sollten in irgendeiner Form in der Themen-Oberfläche erscheinen…
Ein wichtiger Punkt, der hier beachtet werden sollte, ist, dass „Chat“-Implementierungen in der Regel den eigentlichen Inhalt an die Abonnenten broadcasten.
In Discourse haben wir eine ziemlich komplexe Pipeline, die eine naive Implementierung komplex macht und zu einem hohen Datenaufkommen führt.
Ein Benutzer antwortet
Alle Benutzer, die das Thema ansehen, erfahren per Broadcast, dass neuer Inhalt vorhanden ist
Alle Benutzer fragen den Server nach dem Beitraginhalt ab (100 Zuschauer = 100 Anfragen)
Wir laden Bilder herunter und optimieren sie
Alle Benutzer, die das Thema ansehen, erfahren per Broadcast, dass neuer Inhalt vorhanden ist
Alle Benutzer fragen den Server nach dem Beitraginhalt ab (100 Zuschauer = 100 Anfragen)
(Wir haben verschiedene Optimierungen, Ratenbegrenzungen, Wiederholungsversuche usw., aber das ist der Kern)
Alle diese Anfragen müssen durch unsere Sicherheitspipeline laufen, um sicherzustellen, dass der Benutzer die Berechtigung hat, den Beitrag zu sehen, und so weiter.
Wenn der Inhalt eher kurz wäre und wir herausfinden könnten, wie wir die Sicherheit für die „schnelle Spur“ leichter gestalten können, könnten wir die Chat-Nachrichten per Broadcast verteilen. Das würde zu einer deutlich besseren Leistung führen; wir könnten mit diesem Design wahrscheinlich 10.000 Benutzer auf einem einzigen kleinen DigitalOcean-Droplet mit 2 GB RAM handhaben.
Sicherheit ist sehr komplex. Auch das Caching ist komplex aufgrund von Problemen mit der Cache-Invalidierung.
Also, ja, wir beschäftigen uns absolut mit diesem Problem. Aber so wie es derzeit aussieht …
Viele angemeldete Zuschauer in einem Thema + viel neuer Inhalt in einem Thema = teure Serverrechnungen.
Um ehrlich zu sein, weiß ich gerade genug, um gefährlich zu sein. Ich bin der Typ, der durch Ausprobieren (und Zerstören) lernt. Ich weiß die enorme Leistung bei der Erstellung dieser Plattform sehr zu schätzen. Als ich vor 12 Monaten mein erstes Forum erstellt habe, habe ich 12 verschiedene Versionen ausprobiert Vanilla, MyBB, SMF, Flarum usw. Discourse war mit Abstand das Beste.
Einer der größten Pluspunkte ist die aktive Weiterentwicklung. Es ist großartig zu sehen, wie ihr auf die Community hört und die Plattform kontinuierlich verbessert.
Wenn Sie über genügend Speicherplatz verfügen, schadet mehr Swap nicht. free zeigt Ihnen, wie der Speicher verwendet wird und wie viel Swap verwendet wird.
Vanilla, MyBB, SMF, Flarum usw. Discourse war mit Abstand das Beste.
)