J’explore un cas d’utilisation alternatif pour le plugin Discourse Chat et j’ai quelques questions sur ses limites de performance, notamment en ce qui concerne la conservation des données et une utilisation intensive de l’API.
Pour donner un peu de contexte, nous recherchons un système de commentaires à fils. La fonctionnalité de « réponses dans les fils » du plugin Chat offre une expérience utilisateur beaucoup plus proche de nos besoins que la structure standard sujet/message. Pour cette raison, nous envisageons d’utiliser les canaux de chat comme fils de commentaires persistants.
En raison de ce cas d’utilisation, nous aurions besoin de conserver l’historique du chat indéfiniment. Cela soulève notre principale préoccupation : la performance à très grande échelle.
Notre utilisation projetée est élevée :
Messages totaux : Quelque part entre 1 et 10 millions de messages.
Canaux : Environ 150 à 200 canaux.
Nos principales questions sont les suivantes :
Est-il possible de désactiver complètement la conservation du chat ou de l’augmenter pour prendre en charge le nombre de messages mentionné ? Par exemple, en définissant la période de conservation sur 0 ou un nombre très élevé.
Comment la performance de l’API serait-elle affectée ? Nous prévoyons d’utiliser intensivement les API du plugin Chat pour nous intégrer à notre système externe. Notre principal modèle d’accès consisterait à récupérer les messages dans l’ordre chronologique (du plus récent au plus ancien) pour les canaux principaux et les fils. Ce type de sondage fréquent de l’API sur des canaux avec des historiques massifs créerait-il une charge serveur significative ?
Quel serait l’impact général sur la performance du serveur et de la base de données du stockage permanent de millions de messages de chat ? Plus précisément, comment cela affecterait-il :
L’utilisation du CPU et de la RAM du serveur ?
La réactivité globale du site ?
Existe-t-il des « points de rupture » connus ou des limites souples où la performance du système commence à se dégrader considérablement sous ce type de charge ?
Nous comprenons qu’il s’agit d’une utilisation non conventionnelle du plugin de chat et que la désactivation de la conservation n’est pas une bonne pratique. Notre objectif est de déterminer les limites architecturales du système — tant dans l’interface utilisateur que via l’API — avant de nous engager dans cette approche.
Toute information de la part de l’équipe ou des membres de la communauté qui ont utilisé le chat à grande échelle serait incroyablement précieuse.
Salut @Nima1, je peux commencer à répondre à certaines de ces questions :
Oui, c’est possible. Vous pouvez définir chat channel retention days sur « 0 » pour conserver les messages indéfiniment — mais compte tenu de l’ampleur de ce que vous faites, vous avez raison de vous interroger sur les impacts sur les performances. Je note également que nous ne prenons pas actuellement en charge la recherche de messages de discussion (nous y pensons, mais ce n’est pas actuellement prévu). Cela signifie que même si vous conservez les messages indéfiniment, compte tenu de votre utilisation intensive du projet, il peut ne pas être possible pour les membres de trouver des messages spécifiques.
Je ne suis pas certain des réponses à ces questions, laissez-moi vérifier auprès de certains des ingénieurs qui ont le plus travaillé sur le chat pour voir ce qu’ils en pensent.
J’aimerais également en savoir plus sur votre cas d’utilisation — seriez-vous prêt à partager plus de détails sur ce que vous essayez de réaliser ?
Merci pour votre réponse et pour avoir vérifié auprès de l’équipe d’ingénierie. Je serais heureux de partager plus d’informations sur notre cas d’utilisation.
Nous construisons une communauté pour les passionnés de cryptomonnaies. Pour chaque actif crypto majeur, nous voulons créer un canal dédié et persistant pour la discussion en temps réel.
Nous avons constaté que le modèle standard de sujet/publication n’est pas idéal pour cela car :
Rythme et format : Les conversations sont rapides et consistent en des messages courts, des mises à jour et des réactions, ce qui correspond naturellement au format de chat.
Flux d’informations : Nos utilisateurs ont besoin de voir les messages les plus récents en premier et de remonter pour l’historique récent, ce qui est le comportement par défaut dans le chat. En revanche, les sujets sont conçus pour être lus chronologiquement, du plus ancien au plus récent.
Les réponses groupées et l’affichage anti-chronologique du plugin de chat correspondent parfaitement à l’expérience utilisateur que nous voulons créer.
Notre principal défi est l’échelle. Parce que nous aurons un canal pour chaque actif, nous prévoyons d’avoir besoin de centaines de canaux, chacun pouvant potentiellement contenir un très long historique. C’est pourquoi nous sommes si intéressés par les limites de performance.
Nous nous engageons à utiliser Discourse en raison de ses puissantes fonctionnalités de modération, de gestion des utilisateurs et de gamification, qui sont essentielles pour bâtir une communauté saine.
J’ai hâte d’entendre ce que les ingénieurs pensent. Merci encore !
Merci de partager davantage ce que vous espérez faire, @Nima1 !
Après avoir discuté avec notre équipe, je crains que nous ne puissions pas nous prononcer avec certitude sur l’impact de ce volume de messages sur les performances — peu de personnes utilisent actuellement le chat à cette échelle et l’endroit où vous choisissez d’héberger votre site aura un impact important.