Ma suggestion serait d’évaluer les produits de chat dans le but de les intégrer de manière transparente.
Ephemera n’a pas sa place dans Discourse.
Ma suggestion serait d’évaluer les produits de chat dans le but de les intégrer de manière transparente.
Ephemera n’a pas sa place dans Discourse.
Vous devrez être très prudent ici. Peut-être avoir un seul sujet de « chat » à la fois et supprimer les anciens avec rigueur, car chaque mégasujet qui persiste impose une pénalité de performance intense au serveur, et cette pénalité augmente avec chaque vue de page.
Il est préférable d’intégrer un véritable outil de chat, comme indiqué ici :
Je suis entièrement d’accord avec cela. Parfois, ils apportent une valeur à la communauté, mais pas à un point justifiant des modifications du code, selon moi.
Pourriez-vous développer un peu sur cette pénalité de performance ? Cela concerne-t-il les sujets fermés et archivés ? Fermer les sujets à 10 000 messages est acceptable, mais les supprimer serait une toute autre affaire.
Ma communauté adore Discourse et fonctionne sous forme de forum depuis plus de 15 ans. Ils n’utiliseront pas de salon de chat et réagiraient très négativement à la suppression d’anciens sujets. Si le simple fait que ces sujets existent entraîne un problème de performance sérieux et croissant, je devrai soit les rendre sous forme de pages statiques, soit migrer vers une autre plateforme.
Je comprends que notre communauté ne correspond pas tout à fait à la façon dont vous envisagez l’utilisation de Discourse, mais c’est la communauté dont je suis responsable, et il y a des changements que je ne peux pas leur imposer. En fait, notre communauté n’a jamais été aussi forte qu’aujourd’hui avec Discourse. J’aimerais éviter de devoir migrer vers une autre plateforme alors que tout le monde est si satisfait de notre configuration actuelle.
Les mégas-sujets doivent être en grande partie masqués — même s’ils sont fermés et/ou archivés, plus il y a d’utilisateurs qui accèdent à un mégasujet, plus votre serveur sera lent. Idéalement, les mégasujets devraient être supprimés afin que vous n’en ayez qu’un seul actif à la fois ? C’est ma recommandation. Plus vous avez de mégasujets, plus vous prenez de risques.
Si vous pouvez investir beaucoup d’argent pour résoudre ce problème, vous pourriez surdimensionner massivement votre serveur et prendre en charge plus de mégasujets — mais cela affectera toujours les performances médianes pour tous les sujets.
Même lorsqu’un sujet est fermé, il génère des données, du trafic et de la charge.
N’oubliez pas que la position de lecture de chaque utilisateur est enregistrée pour chaque sujet. Chaque message peut être aimé, l’interaction avec les mégasujets reste possible même après leur fermeture, sans parler du bruit qu’ils peuvent introduire dans vos résultats de recherche.
Cela n’explique toujours pas pourquoi les mégasujets en particulier posent problème. Pourquoi un sujet de 10 000 messages est-il pire que dix sujets de 1 000 messages chacun ? Dans ce dernier cas, le nombre total de messages susceptibles d’être aimés ou recherchés est le même, mais il y a dix fois plus de positions de lecture et de sujets à rechercher. Sur la base de votre explication uniquement, je conclurais qu’un plus grand nombre de petits sujets est pire. Il doit donc y avoir d’autres facteurs en jeu.
Parce que vous chargez un seul sujet à la fois. Vous pouvez récupérer dix sujets de 1 000 <insérez un élément léger ici> un par un sans problème, mais en récupérer 10 000 d’un coup est beaucoup plus difficile.
Je suis cependant curieux de connaître les détails. Seuls un certain nombre de messages sont chargés par défaut avant que vous ne défiliez, ce qui montre clairement que ce n’est pas dû au nombre de messages visibles. Est-ce lié à la chronologie ? À la synthèse du sujet ? Ou plus généralement à divers algorithmes linéaires ou supérieurs à la linéarité basés sur le nombre total de messages dans le sujet ?
Je ne m’intéresse pas vraiment aux mégasujets, selon ce que vous considérez comme « méga ». Dans la section que je fréquente le plus dans la communauté que j’utilise, le sujet le plus actif compte environ 3 600 messages, mais le 10e n’en compte que 600. Le 25e n’en compte que 300. Pour l’instant, ma curiosité est plutôt d’ordre technique.
Voici une requête d’explorateur de données que j’ai écrite pour tenter de répondre à votre question. Vous pouvez l’essayer avec différents sujets et décalages.
-- [params]
-- int :topic_id = 107216
-- int :offset = 10000
SELECT "posts"."id" FROM "posts"
WHERE ("posts"."deleted_at" IS NULL)
AND "posts"."topic_id" = :topic_id
AND "posts"."post_type" IN (1,2,3) ORDER BY "posts"."sort_order" ASC LIMIT 20
OFFSET :offset
Voici un sujet de taille normale et un sujet énormément volumineux :
Exemple : 3,4 ms
-> Balayage d'index utilisant index_posts_on_topic_id_and_sort_order sur posts (cost=0.43..1925.22 rows=477 width=8)
Exemple : 353,9 ms, 739,6 ms (le temps varie selon la mise en cache de la base de données)
-> Balayage d'index utilisant index_posts_on_topic_id_and_sort_order sur posts (cost=0.43..605155.88 rows=161255 width=8)
Je pense avoir observé des temps supérieurs à 750 ms.
Voici les temps médians et au 99e percentile. Le temps médian est étonnamment bon, mais la nature de la médiane fait que l’on ne peut pas savoir si, au 60e percentile, la performance est beaucoup, beaucoup plus mauvaise que dans le cas médian.
Voici un autre serveur (il possède un nombre stupéfiant de catégories, ce qui affecte également ses performances, donc la comparaison n’est pas tout à fait équivalente sans mégasujets), mais vous pouvez voir que la performance médiane est divisée par deux et que le pire cas est également bien meilleur :
Moi aussi, simplement par curiosité.
Je comprends que la navigation dans un mégasujet puisse entraîner de mauvaises performances, comme l’explique ce passage :
Cependant, je ne comprends pas comment un ou plusieurs mégasujets peuvent affecter la navigation sur d’autres pages du forum, y compris par exemple la liste des sujets. ![]()
En ajoutant beaucoup de charge au serveur. Chaque chargement de mégasujet équivaut à une pénalité de performance 100 fois plus importante ! Voyez le message directement au-dessus du vôtre.
Bonjour,
Le forum que j’importe actuellement vers Discourse contient de nombreux sujets géants :
Comme les sujets géants ne fonctionnent pas bien avec Discourse, que devrais-je faire concrètement ? (Je compte proposer un chat à l’avenir pour la communauté, peut-être Discord, mais je souhaite savoir quoi faire avec les sujets actuels).
Les supprimer ?
Les diviser et les fermer ?
Si je les divise, combien de messages par sujet ? La valeur par défaut de 10 000 est-elle suffisante, ou conseillez-vous de la réduire ?
Le découpage en 10 000 fragments devrait suffire.
De plus, la plupart de ceux-ci semblent corrects. Les vrais dégâts commencent à 10k, et la plupart de ce qui est montré dans la capture d’écran est bien inférieur à 10k.
Quelles sont les dernières informations concernant l’impact sur les performances du sujet majeur ? Notre sujet de suivi de la pandémie de COVID approche des 10 000 publications et nous analysons les éventuels ralentissements récents.
Je ne sais pas quelles devraient être les statistiques « idéales » d’un serveur, mais je peux partager les nôtres pour une communauté comptant de nombreux mégasujets. Nous avons actuellement 15 sujets fermés avec 10 000 messages chacun et plus de 50 sujets ouverts avec plus de 2 000 messages. La majeure partie de l’activité du forum se concentre à tout moment sur un nombre relativement restreint de sujets très actifs.
Nous utilisons actuellement un serveur DigitalOcean doté de 4 CPU virtuels, 8 Go de mémoire et 160 Go de stockage, pour un coût de 40 $ par mois. Peut-être une fois tous les quelques mois, certains utilisateurs recevront brièvement le message « charge extrême ». Cela ne se produit que lors d’événements en direct où de nombreux utilisateurs publient simultanément — par exemple, plusieurs messages par minute dans un seul sujet sur une période d’une ou deux heures.
À tous les autres moments, les performances sont fluides et sans problème. Nous sommes actuellement sur la voie de devoir ajouter de l’espace disque bien avant de devoir mettre à niveau tout le reste.
C’est un bon nombre, 2 000 messages n’est pas grave, quelques dizaines de sujets de plus de 10 000 messages devraient aller (surtout s’ils sont fermés), la zone de danger est quand vous avez beaucoup de mégasujets actifs. Je définira « beaucoup » comme plus de quelques dizaines.
Bien que les sujets massifs ne posent généralement pas de problème ici chez Meta, ils semblent être une façon naturelle d’organiser les discussions pour de nombreuses communautés. Autrement dit, la discussion n’a pas de point de rupture naturel.
Inderes est une entreprise finlandaise qui fournit des analyses financières pour le marché boursier. Ils ont récemment lancé leur communauté Discourse, qui a connu un succès massif, compte tenu de la région et du créneau.
Les discussions sont principalement organisées par action ou véhicule d’investissement. Par exemple, $AAPL ou $TSLA. En seulement deux ans environ, de nombreux sujets de ce type approchent la barre des 10 000 messages. Une preuve de concept fantastique pour Discourse (une communauté dynamique construite à partir de zéro), mais qui souligne également le problème des sujets massifs.
Si rien d’autre, vous pouvez la découper par année. Cela est expliqué dans le premier message. Les mégasujets peuvent fonctionner pendant un certain temps, mais s’il y en a trop, ils finiront par faire tomber votre site.
(De plus, la recherche devient un cauchemar lorsque vous avez des dizaines de milliers de messages dans le même « sujet », etc. — fondamentalement, vous avez construit un salon de discussion.)