Ik onderzoek een alternatieve use case voor de Discourse Chat-plugin en heb enkele vragen over de prestatielimieten, met name met betrekking tot gegevensretentie en zwaar API-gebruik.
Om wat context te geven, zijn we op zoek naar een systeem met “threaded” reacties. De functie “threaded replies” binnen de Chat-plugin biedt een gebruikerservaring die veel dichter bij onze behoeften ligt dan de standaard topic/post-structuur. Om deze reden overwegen we chatkanalen te gebruiken als permanente commentaartthreads.
Vanwege deze use case zouden we de chatgeschiedenis onbeperkt moeten bewaren. Dit leidt tot onze belangrijkste zorg: prestaties op zeer grote schaal.
Ons verwachte gebruik is hoog:
Totaal aantal berichten: Ergends tussen 1 en 10 miljoen berichten.
Kanalen: Ongeveer 150 tot 200 kanalen.
Onze belangrijkste vragen zijn:
Is het mogelijk om de retentie van chatberichten volledig uit te schakelen of te verhogen om het genoemde aantal berichten te ondersteunen? Bijvoorbeeld door de retentieperiode in te stellen op 0 of een zeer groot getal.
Hoe zouden de API-prestaties worden beïnvloed? We zijn van plan de API’s van de Chat-plugin intensief te gebruiken om te integreren met ons externe systeem. Ons primaire toegangspatroon zou het ophalen van berichten in chronologische volgorde (nieuwste eerst) zijn voor zowel hoofdkanalen als threads. Zou dit soort frequente API-polling op kanalen met enorme geschiedenissen een aanzienlijke serverbelasting veroorzaken?
Wat zou de algemene impact op de prestaties van de server en database zijn van het permanent opslaan van miljoenen chatberichten? Hoe zou dit specifiek van invloed zijn op:
Server CPU- en RAM-gebruik?
Algemene site-responsiviteit?
Zijn er bekende “breekpunten” of zachte limieten waarbij de prestaties van het systeem aanzienlijk beginnen af te nemen onder dit soort belasting?
We begrijpen dat dit een onconventioneel gebruik van de chat-plugin is en dat het uitschakelen van retentie geen best practice is. Ons doel is om de architecturale limieten van het systeem te bepalen – zowel in de UI als via de API – voordat we ons aan deze aanpak committeren.
Alle inzichten van het team of communityleden die chat op grote schaal hebben gebruikt, zouden enorm waardevol zijn.
Hey @Nima1, I can start to answer some of these questions:
Yes, it’s possible. You can set the chat channel retention days to “0” to retain messages forever — but given the scale of what you’re doing, you’re right to wonder about performance impacts. I’ll also note that we do not currently support searching chat messages (it’s on our minds but is not currently planned). This means that even if you are retaining messages forever, given your high project usage, it may not be feasible for members to find specific messages.
I’m not positive about the answers to these questions, let me check with some of the engineers who have worked on chat the most to see what they think.
I’d also love to learn more about your use case — would you be willing to share some more detail about what you’re working toward?
Bedankt voor je reactie en voor het navragen bij het engineeringteam. Ik deel graag meer over ons gebruiksscenario.
We bouwen een community voor liefhebbers van cryptocurrency. Voor elk belangrijk crypto-bezit willen we een speciaal, persistent kanaal creëren voor realtime discussie.
We hebben gemerkt dat het standaard onderwerp/post-model hier niet ideaal voor is omdat:
Tempo & Formaat: De gesprekken zijn snel en bestaan uit korte berichten, updates en reacties, wat goed past bij het chatformaat.
Informatie stroom: Onze gebruikers moeten eerst de nieuwste berichten zien en omhoog scrollen voor de recente geschiedenis, wat het standaardgedrag is in chat. In tegenstelling hiermee zijn onderwerpen ontworpen om chronologisch van oud naar nieuw te worden gelezen.
De threaded replies en de omgekeerde chronologische weergave van de chatplugin passen perfect bij de gebruikerservaring die we willen creëren.
Onze grootste uitdaging is schaal. Omdat we een kanaal voor elk bezit zullen hebben, verwachten we honderden kanalen nodig te hebben, die elk mogelijk een zeer lange geschiedenis bevatten. Daarom zijn we zo geïnteresseerd in de prestatielimieten.
We zijn vastbesloten om Discourse te gebruiken vanwege de krachtige moderatie-, gebruikersbeheer- en gamification-functies, die cruciaal zijn voor het opbouwen van een gezonde community.
Ik kijk ernaar uit om te horen wat de ingenieurs ervan denken. Nogmaals bedankt!
Bedankt voor het delen van meer over wat je hoopt te doen, @Nima1!
Na overleg met ons team, ben ik bang dat we niet met zekerheid kunnen zeggen hoe de prestaties zouden worden beïnvloed door dit aantal berichten - we hebben niet veel mensen die nu op deze schaal chatten en waar je je site host, zal een grote impact hebben.