Unsere Discourse-Website hat über 10.000 Benutzer und etwa 700 täglich aktive Nutzer, die durchschnittlich 10.000 Beiträge pro Tag verfassen. Unsere Community verzeichnet mehr als 160.000 Seitenaufrufe pro Tag, einschließlich Crawler und anonyme Nutzer. Fast alle unsere Benutzer sind über mobile Geräte mit uns verbunden.
Wir haben die Community im Standalone-Modus auf einem einzelnen VPS mit 16 CPU-Kernen und 24 GB RAM betrieben und die Datei app.yml mit folgenden Werten konfiguriert:
Mit der obigen Konfiguration berichten einige Benutzer, dass die Seite für sie langsam lädt. Manchmal wird beim Absenden eines Beitrags der Bildschirm schwarz (der Header bleibt jedoch sichtbar). Außerdem verlangsamt sich die Performance der Seite manchmal während der Spitzenzeiten.
Bitte erläutern Sie, ob wir die Konfiguration falsch vorgenommen haben oder ob mehr Ressourcen benötigt werden.
Vielen Dank
10.000 Beiträge pro Tag sind im Verhältnis zur Anzahl der Seitenaufrufe ziemlich hoch. Ich kann mir vorstellen, dass Sie hier aufgrund Ihrer Konfiguration an Ressourcenlimits stoßen, und ich vermute, dass es sich um die Datenbank handelt. Sie könnten versuchen, auf ein Multi-Container-Setup umzusteigen und so die Unicorn-Worker effektiv von der Hauptserver entlasten.
Entsprechend Ihrer Antwort hilft es nicht, die Ressourcen in diesem Setup zu erhöhen, um unser Problem zu lösen? Zum Beispiel 24 CPU-Kerne mit 32 GB RAM.
Das könnte durchaus der Fall sein, aber ich würde zunächst versuchen, alles, was horizontal skaliert werden kann, horizontal zu skalieren. Das gibt dir auch eine viel bessere Vorstellung davon, wo dein Flaschenhals liegt.
Die meisten Leistungsprobleme lassen sich lösen, indem man einfach mehr Ressourcen auf das Problem wirft. Der schwierige Teil besteht darin, das auf intelligente Weise zu tun, damit du etwas Geld (oder potenziell eine Menge Geld) sparen kannst.
Vielen Dank für Ihre Expertise und Ihren freundlichen Rat. Ich werde auf jeden Fall lesen, wie man dies umsetzt. Eine weitere Frage von mir ist, welche Einstellungen in der App für die oben genannten Spezifikationen angewendet werden sollten (24 CPU-Kerne mit 32 GB RAM). Sind die aktuellen Einstellungen angemessen oder ist es besser, die Werte zu erhöhen?
Ohne das System zu untersuchen und zu sehen, was los ist, lässt sich das schwer sagen.
Da Sie sagten, dass die meisten Probleme beim Absenden eines Beitrags auftreten, liegt das Problem wahrscheinlich bei Datenbank-Schreibvorgängen. Ich glaube nicht, dass eine weitere Erhöhung von shared buffers viel bringt, aber Sie können es versuchen. Ich habe gesehen, dass es entgegen aller Ratschläge auf über 50 % des Speichers hochgefahren wurde, also können Sie versuchen, es schrittweise auf bis zu 12 GB zu erhöhen.
Wenn Sie keine 502-Fehler sehen, hat es auch keinen Sinn, UNICORN_WORKERS zu erhöhen.
Du erwähnst nicht, dass du es verwendest, daher denke ich, dass das Erste, was ich tun würde, das Hinzufügen eines CDNs ist. Dies würde die Last auf dem VPS erheblich verringern, da größere Anfragen den Server nicht berühren würden.
Zusätzlich zum CDN würde ich auch einen S3-ähnlichen Speicher verwenden, der es dir ermöglicht, Speicher und VPS-Ressourcen unabhängig voneinander zu skalieren (falls deine Community viele Uploads hat).
Diese Empfehlungen helfen sehr stark, die Last zu reduzieren, und die Preiserhöhung ist viel geringer als bei einem größeren VPS.
Danke @marianord, leider nutzen wir kein CDN. Die Upload-Rate in unserem Forum ist nicht sehr hoch. Die meisten Nutzer sprechen über verschiedene Themen. Zum Beispiel hatten wir im letzten Jahr etwa 2,8 Millionen Beiträge und 2,7 Millionen Likes, aber nur 25 GB Dateien wurden hochgeladen.
Denkst du, dass die Nutzung eines CDNs wie S3 basierend auf den von mir genannten Informationen die Serverlast reduzieren würde?
Ich stimme @marianord nicht zu. Ich denke nicht, dass ein CDN einen spürbaren Unterschied für die Auslastung deines Servers machen würde. Es handelt sich hier lediglich um statische Dateien, die überhaupt nicht schwer zu bedienen sind.
S3 entlastet die Dateien und Backups auf einen anderen Server, der von einem Cloud-Anbieter verwaltet wird (sehr grobe Zusammenfassung).
CDN cacht die statischen Dateien deines Servers (Bilder, JS, CSS), um sie von mehreren Servern (PoP) weltweit auszuliefern und so die Ladezeit dieser Assets zu beschleunigen.
Zumindest ist das meine Erfahrung: Du reduzierst die Anzahl der Anfragen, die bei deinem Server ankommen, und damit auch die Last. Es ist viel einfacher, nur 10 JSON-Anfragen pro Benutzer zu bedienen als 100 Anfragen pro Benutzer.
Vielleicht löst dies nicht alle Probleme, mit denen @nildarar konfrontiert ist, aber es wird die hohe Last auf dem Server verringern, indem alle statischen Anfragen (die gecachten) vom Discourse-Server entfernt werden.
Eine Anfrage für eine statische Datei hat keinen großen Einfluss auf die Gesamtlast des Servers. Die Anfragen für dynamische Inhalte sind die, die wirklich belasten.
Im Allgemeinen ist eine json-Anfrage kein statisches Asset, das von einem CDN zwischengespeichert wird. Es handelt sich um dynamische Inhalte, die im Moment der Anfrage generiert werden. Warum sprichst du in einem CDN-Kontext von JSON-Dateien?
Statische Anfragen ≠ höhere Last.
Entschuldigung, aber das ist wirklich schlechte Beratung.
Hier ist ein Beispiel von einer Maschine mit 6 CPUs (die CPU-Leistung addiert sich also auf 600 %), auf der Discourse ohne CDN oder S3 läuft.
Stimmt, aber Discourse hat einige Ausnahmen, wie Stylesheets, die von Ruby ausgeliefert werden. Daher bedeutet ein Caching-CDN, dass diese Anfragen keine Unicorn-Prozesse beanspruchen.
Bezüglich des Problems des ursprünglichen Posters ist als Erstes erforderlich, dass eine sachkundige Person während der Stoßzeiten eine Leistungsanalyse durchführt und ermittelt, wo aktuell der Flaschenhals liegt.
Vielen Dank für Ihre Anleitung. Bis vor einigen Monaten nutzten wir den Cloudflare-CDN-Dienst und haben durch Page Rules erhebliche Verbesserungen bei statischen Inhalten erzielt. Danach habe ich irgendwo gelesen, dass die Verwendung von Proxys wie Cloudflare die Leistung von Discourse drastisch verringert, weshalb wir es deaktiviert haben.
Gestern haben wir die Anzahl der CPU-Kerne von 16 auf 24 erhöht und folgende Änderungen in der app.yml vorgenommen:
Mit diesen Änderungen wurde unser Problem vorübergehend gelöst, aber ich denke, wir sollten in den nächsten Monaten eine grundlegende Änderung vornehmen.
Entsprechend Ihren Empfehlungen hat die Nutzung eines CDNs für die Auslieferung statischer Inhalte sowie die Aufteilung von Discourse in zwei separate Container bei den Leistungsverbesserungen höchste Priorität.
Das sind möglicherweise veraltete Informationen, aber ich erinnere mich, gelesen zu haben, dass Discourse eine geringere Anzahl leistungsfähigerer CPUs einer höheren Anzahl schwächerer CPUs vorzieht … selbst wenn man die Anzahl der Unicorn-Worker aktualisiert.
@codinghorror, kannst du bestätigen, ob diese Information noch zutrifft?
Unsere Prognose besagt, dass sich die Anzahl unserer Nutzer im nächsten Jahr verdreifachen wird. Daher müssen wir ab heute die erforderlichen Ressourcen für dieses Wachstum bereitstellen.
Die Verwendung von Tools wie Prometheus + Grafana kann Ihnen helfen, den historischen Verlauf der Daten zu erhalten, anstatt sie live zu betrachten und anschließend eine tiefere Analyse dessen durchzuführen, was gerade passiert.
Hallo nochmal
Nach Ihren Tipps haben wir Prometheus installiert und die Community-Leistung eine Weile überwacht. Bitte sehen Sie sich die unten stehenden Berichte an und vergleichen Sie die Werte mit denen, die Sie in verschiedenen Installationen sehen.
