Ich untersuche einen alternativen Anwendungsfall für das Discourse Chat Plugin und habe einige Fragen zu seinen Leistungsgrenzen, insbesondere in Bezug auf die Datenspeicherung und intensive API-Nutzung.
Um etwas Kontext zu geben: Wir suchen nach einem System für verschachtelte Kommentare. Die Funktion „verschachtelte Antworten“ im Chat-Plugin bietet eine Benutzererfahrung, die unseren Anforderungen viel näher kommt als die Standard-Themen-/Post-Struktur. Aus diesem Grund erwägen wir die Verwendung von Chat-Kanälen als dauerhafte Kommentar-Threads.
Aufgrund dieses Anwendungsfalls müssten wir den Chat-Verlauf unbegrenzt aufbewahren. Dies führt zu unserer Hauptsorge: Leistung bei sehr großer Skalierung.
Unsere prognostizierte Nutzung ist hoch:
Gesamte Nachrichten: Irgendwo zwischen 1 und 10 Millionen Nachrichten.
Kanäle: Ungefähr 150 bis 200 Kanäle.
Unsere primären Fragen sind:
Ist es möglich, die Chat-Aufbewahrung vollständig zu deaktivieren oder zu erhöhen, um die genannten Nachrichtenanzahlen zu unterstützen? Zum Beispiel durch Festlegen der Aufbewahrungsfrist auf 0 oder eine sehr große Zahl.
Wie würde sich die API-Leistung auswirken? Wir planen, die Chat-Plugin-APIs intensiv zu nutzen, um sie in unser externes System zu integrieren. Unser primäres Zugriffsmuster wäre das Abrufen von Nachrichten in chronologischer Reihenfolge (neueste zuerst) sowohl für Hauptkanäle als auch für Threads. Würde diese Art von häufigem API-Polling auf Kanälen mit riesigen Verläufen eine signifikante Serverlast erzeugen?
Welche allgemeinen Leistungsauswirkungen hätte die dauerhafte Speicherung von Millionen von Chat-Nachrichten auf den Server und die Datenbank? Insbesondere, wie würde sich dies auf Folgendes auswirken:
Server-CPU- und RAM-Auslastung?
Gesamte Website-Reaktionsfähigkeit?
Gibt es bekannte „Bruchpunkte“ oder weiche Limits, bei denen die Systemleistung unter dieser Art von Last signifikant zu sinken beginnt?
Wir verstehen, dass dies eine unkonventionelle Nutzung des Chat-Plugins ist und dass die Deaktivierung der Aufbewahrung keine bewährte Methode ist. Unser Ziel ist es, die Architekturgrenzen des Systems – sowohl in der Benutzeroberfläche als auch über die API – zu ermitteln, bevor wir uns für diesen Ansatz entscheiden.
Jede Einsicht vom Team oder von Community-Mitgliedern, die Chat in großem Maßstab betrieben haben, wäre unglaublich wertvoll.
Hallo @Nima1, ich kann einige dieser Fragen beantworten:
Ja, das ist möglich. Sie können die chat channel retention days auf „0“ setzen, um Nachrichten für immer aufzubewahren – aber angesichts des Umfangs dessen, was Sie tun, fragen Sie sich zu Recht nach den Auswirkungen auf die Leistung. Ich möchte auch darauf hinweisen, dass wir derzeit keine Suche nach Chat-Nachrichten unterstützen (wir denken darüber nach, aber es ist derzeit nicht geplant). Das bedeutet, dass es selbst bei einer unbegrenzten Aufbewahrung von Nachrichten aufgrund Ihrer hohen Projektverwendung für Mitglieder möglicherweise nicht praktikabel ist, bestimmte Nachrichten zu finden.
Ich bin mir bei den Antworten auf diese Fragen nicht sicher, lassen Sie mich mit einigen der Ingenieure sprechen, die am meisten an Chat gearbeitet haben, um zu sehen, was sie denken.
Ich würde auch gerne mehr über Ihren Anwendungsfall erfahren – wären Sie bereit, mehr Details darüber zu teilen, worauf Sie hinarbeiten?
vielen Dank für die Antwort und die Rücksprache mit dem Engineering-Team. Gerne teile ich mehr über unseren Anwendungsfall mit.
Wir bauen eine Community für Kryptowährungs-Enthusiasten auf. Für jeden wichtigen Krypto-Asset möchten wir einen dedizierten, persistenten Kanal für Echtzeit-Diskussionen erstellen.
Wir haben festgestellt, dass das Standard-Topic/Post-Modell dafür nicht ideal ist, weil:
Tempo & Format: Die Gespräche sind schnelllebig und bestehen aus kurzen Nachrichten, Updates und Reaktionen, was gut zum Chat-Format passt.
Informationsfluss: Unsere Nutzer müssen die neuesten Nachrichten zuerst sehen und nach oben scrollen, um die jüngste Historie zu sehen, was das Standardverhalten im Chat ist. Im Gegensatz dazu sind Topics dafür konzipiert, chronologisch von alt nach neu gelesen zu werden.
Die Threaded Replies und die umgekehrt-chronologische Anzeige des Chat-Plugins passen perfekt zu dem Nutzererlebnis, das wir schaffen wollen.
Unsere größte Herausforderung ist die Skalierbarkeit. Da wir für jeden Asset einen Kanal haben werden, erwarten wir Hunderte von Kanälen, von denen jeder potenziell eine sehr lange Historie enthalten könnte. Deshalb sind wir so an den Leistungsgrenzen interessiert.
Wir sind entschlossen, Discourse wegen seiner leistungsstarken Moderations-, Benutzerverwaltungs- und Gamification-Funktionen zu nutzen, die für den Aufbau einer gesunden Community unerlässlich sind.
Ich freue mich darauf, zu hören, was die Ingenieure denken. Nochmals vielen Dank!
Danke, dass Sie mehr darüber erzählen, was Sie vorhaben, @Nima1!
Nachdem ich mit unserem Team gesprochen habe, befürchte ich, dass wir keine genauen Aussagen darüber treffen können, wie sich die Leistung auf dieses Nachrichtenvolumen auswirken würde – wir haben derzeit nicht viele Leute, die den Chat in diesem Umfang nutzen, und wo Sie Ihre Website hosten, wird einen großen Einfluss haben.