Sto esplorando un caso d’uso alternativo per il plugin Discourse Chat e ho alcune domande sui suoi limiti di prestazioni, in particolare per quanto riguarda la conservazione dei dati e l’uso intensivo delle API.
Per fornire un po’ di contesto, stiamo cercando un sistema di commenti a thread. La funzionalità “risposte a thread” all’interno del plugin Chat offre un’esperienza utente molto più vicina alle nostre esigenze rispetto alla struttura standard di topic/post. Per questo motivo, stiamo prendendo in considerazione l’utilizzo dei canali di chat come thread di commenti persistenti.
A causa di questo caso d’uso, avremmo bisogno di mantenere la cronologia della chat a tempo indeterminato. Questo porta alla nostra principale preoccupazione: le prestazioni su larga scala.
Il nostro utilizzo previsto è elevato:
Messaggi totali: Tra 1 e 10 milioni di messaggi.
Canali: Circa 150-200 canali.
Le nostre domande principali sono:
È possibile disabilitare completamente la conservazione della chat o aumentarla per supportare il numero di messaggi menzionato? Ad esempio, impostando il periodo di conservazione a 0 o a un numero molto elevato.
Come verrebbero influenzate le prestazioni delle API? Abbiamo in programma di utilizzare ampiamente le API del plugin Chat per integrarlo con il nostro sistema esterno. Il nostro modello di accesso principale consisterebbe nel recuperare i messaggi in ordine cronologico (dal più recente al meno recente) sia per i canali principali che per i thread. Questo tipo di polling frequente delle API su canali con cronologie massive creerebbe un carico significativo sul server?
Quale sarebbe l’impatto generale sulle prestazioni del server e del database della memorizzazione permanente di milioni di messaggi di chat? In particolare, come influirebbe su:
Utilizzo della CPU e della RAM del server?
Reattività generale del sito?
Esistono “punti di rottura” noti o limiti soft in cui le prestazioni del sistema iniziano a degradarsi significativamente sotto questo tipo di carico?
Comprendiamo che questo è un uso non convenzionale del plugin chat e che la disabilitazione della conservazione non è una best practice. Il nostro obiettivo è determinare i limiti architetturali del sistema, sia nell’interfaccia utente che tramite API, prima di impegnarci in questo approccio.
Qualsiasi approfondimento dal team o dai membri della community che hanno utilizzato la chat su larga scala sarebbe incredibilmente prezioso.
Ciao @Nima1, posso iniziare a rispondere ad alcune di queste domande:
Sì, è possibile. Puoi impostare chat channel retention days su “0” per conservare i messaggi per sempre, ma data la scala di ciò che stai facendo, hai ragione a chiederti quali siano gli impatti sulle prestazioni. Noterò anche che attualmente non supportiamo la ricerca dei messaggi di chat (ci stiamo pensando, ma non è attualmente pianificato). Ciò significa che anche se conservi i messaggi per sempre, dato il tuo elevato utilizzo del progetto, potrebbe non essere fattibile per i membri trovare messaggi specifici.
Non sono sicuro delle risposte a queste domande, fammi controllare con alcuni degli ingegneri che hanno lavorato di più sulla chat per vedere cosa ne pensano.
Mi piacerebbe anche saperne di più sul tuo caso d’uso: saresti disposto a condividere maggiori dettagli su ciò che stai cercando di realizzare?
Grazie per la risposta e per aver verificato con il team di ingegneria. Sarei felice di condividere di più sul nostro caso d’uso.
Stiamo costruendo una community per appassionati di criptovalute. Per ogni asset crittografico importante, vogliamo creare un canale dedicato e persistente per la discussione in tempo reale.
Abbiamo scoperto che il modello standard di argomento/post non è ideale per questo perché:
Ritmo e Formato: Le conversazioni sono rapide e consistono in messaggi brevi, aggiornamenti e reazioni, il che si adatta naturalmente al formato della chat.
Flusso di Informazioni: I nostri utenti devono vedere prima i messaggi più recenti e scorrere verso l’alto per la cronologia recente, che è il comportamento predefinito nella chat. Al contrario, gli argomenti sono progettati per essere letti cronologicamente dal più vecchio al più nuovo.
Le risposte in thread e la visualizzazione in ordine cronologico inverso del plugin di chat si adattano perfettamente all’esperienza utente che vogliamo creare.
La nostra sfida principale è la scalabilità. Poiché avremo un canale per ogni asset, prevediamo di aver bisogno di centinaia di canali, ognuno dei quali potrebbe contenere una cronologia molto lunga. Ecco perché siamo così interessati ai limiti di prestazioni.
Siamo impegnati a utilizzare Discourse grazie alle sue potenti funzionalità di moderazione, gestione degli utenti e gamification, che sono fondamentali per costruire una community sana.
Non vedo l’ora di sapere cosa ne pensano gli ingegneri. Grazie ancora!
Grazie per aver condiviso di più su ciò che speri di fare, @Nima1!
Dopo aver parlato con il nostro team, temo che non possiamo parlare con certezza di come le prestazioni sarebbero influenzate da questo volume di messaggi: non abbiamo molte persone che utilizzano la chat in questo momento su questa scala e dove scegli di ospitare il tuo sito avrà un grande impatto.