Wir hatten gerade einen Spitzenwert von ca. 1.500 gleichzeitigen (meist anonymen) Besuchern auf einer einzigen Seite.
Das Forum hat daraufhin den Modus aktiviert, in dem allen Mitgliedern eine Warnung bezüglich der hohen Auslastung angezeigt wird.
CPU-optimierter Digital Ocean Droplet
Dedizierte CPU: 4 vCPUs
RAM: 8 GB
Unicorn-Worker: 10
Da nur etwa 50 % von RAM und CPU ausgelastet sind, würde es in solchen Spitzenlastfällen mit anonymen Besuchern helfen, die Anzahl der Unicorn-Worker zu erhöhen, oder nicht?
Ich habe die Worker auf 24 erhöht. Keine Änderung (es wird weiterhin angezeigt: „Aufgrund extremer Last wird dies vorübergehend für alle so dargestellt, wie es ein nicht angemeldeter Benutzer sehen würde.“), bei einem ähnlichen Spitzenwert an gleichzeitigen Besuchern (99 % anonym) gerade eben:
@sam Hast du Ideen, wie man sich für Spitzenlasten durch anonyme Besucher weiter optimieren kann (z. B. wenn ein einzelnes Thema in den sozialen Medien viral geht)? In beiden oben genannten Fällen haben Speicher und CPU noch reichlich Reserven (laut DigitalOcean), und wir haben die Last von 4 noch nicht einmal erreicht. Trotzdem gerät das Forum in den Modus „extreme Last“, obwohl die Anzahl der Worker verdreifacht wurde.
Ich bin der Meinung, dass der DO-Datenmonitor nicht empfindlich genug ist und etwas irreführend wirkt. Ich habe extreme Lastsituationen mit Hetzner und Digital Ocean getestet. Bei Hetzner trat bei der Meldung zur extremen Last ein kurzer, steiler Peak auf, der bis auf 120 % anstieg.
Dieser dauerte vielleicht eine Sekunde, bevor er wieder auf den Bereich von 40–50 % zurückfiel.
Ich habe dasselbe Szenario mit Digital Ocean nachgestellt. Nach meiner Erinnerung lag die CPU-Auslastung dort nie über 50 % (allerdings konnte man die X-Achse nicht auf Sekunden-Ebene zoomen).
Meine Vermutung ist, dass die DO-CPU-Auslastung ein Durchschnittswert über 5 oder 15 Sekunden ist. Daher sieht man die kurzen, steilen Spitzen nicht.
Um tiefergehende Analysen durchzuführen, benötigen wir Prometheus-Exporter-Berichte.
Wenn Sie ausreichend RAM und CPU-Leistung haben, können Sie jederzeit weitere Unicorn-Worker hinzufügen, um diese Spitzenlasten zu bewältigen. Wichtig ist lediglich, dass kein Memory-Swapping auftritt, da dies die Performance erheblich beeinträchtigen würde.
In einem solchen Fall scheint es sinnvoll, dass die betreffende Themenseite für einen kurzen Zeitraum zwischengespeichert und statisch ausgeliefert werden kann, ohne dass überhaupt auf das Backend zugegriffen werden muss. Ich habe keine Ahnung, ob Discourse das kann (d. h. Cache-Control-Header unter Last setzen und Inhalte an anonyme Nutzer ausliefern) und ob die DO-Setup-Kette über einen leistungsfähigen Caching-Proxy verfügt, aber das ist eine Entwicklungsidee, die sich lohnen könnte, falls ich mich nicht täusche und dies noch nicht umgesetzt ist.
Vielleicht hat @sam das bereits überlegt oder umgesetzt oder weiß, warum es eine schlechte Idee wäre!
Ja, aber mein Vorschlag ist, nur anonyme Benutzer auf eine zwischengespeicherte Seite mit kurzer Ablaufzeit (60 Sekunden?) umzuleiten, um sie zu entlasten, in der Hoffnung, dass der Rest der Site im Lese-Schreib-Modus weiterläuft.
Das wäre großartig. Momentan versetzt das Hervorheben eines Themas auf unserem Telegram-Kanal mit über 200.000 Teilnehmern die gesamte Discourse-Website für fast eine Stunde in den „Nur-Lese-Modus“. Dabei sind die angemeldeten Nutzer nur etwa 50 (99 % des Traffics ist anonym).
Das passiert bereits. Wir nutzen ein sehr aggressives Caching direkt in Redis für anonyme Benutzer auf den Seiten mit Themenlisten und auf den Themenseiten. Die Timeout-Zeit beträgt 60 Sekunden.
Ich werde versuchen, Prometheus zum Laufen zu bringen, um den Flaschenhals zu identifizieren. Wahrscheinlich liegt es jedoch, wie von @Alec erwähnt, am Monitoring von DigitalOcean, das verzögert ist. Falls dies der Fall ist, gehe ich davon aus, dass eine größere Maschine der richtige Weg ist?
