我的建议是评估聊天产品，目标是将它们无缝集成。Ephemera 不适合 Discourse。
3 个赞
在这里你需要格外小心。或许可以一次只保留一个“聊天”主题，并严格删除旧的主题，因为每个持续存在的超大主题都会给服务器带来严重的性能开销，而且随着每次页面访问，这种开销还会不断增加。
不过，最好还是集成一个真正的聊天工具，详见：
3 个赞
完全同意这一点。有时它们确实为社区增添了价值，但在我看来，其重要性还不足以需要修改代码。
3 个赞
能否详细说明一下这个性能开销？这是针对已关闭和归档的主题吗？在达到 1 万条时关闭主题没问题，但删除它们则是另一回事了。
我的社区非常喜爱 Discourse，并且已经以论坛形式运营了超过 15 年。他们不会使用聊天室，如果删除旧主题，他们会反应非常强烈。如果这些主题仅仅因为存在就会导致严重且日益增长的性能问题，那么我就需要要么将它们渲染为静态页面，要么迁移到其他平台。
我意识到我们的社区并不完全符合您对 Discourse 使用方式的设想，但这就是我负责的社区，有些改变我无法强加给他们。事实上，在使用 Discourse 后，我们的社区从未像现在这样强大。如果所有人都对当前的设置非常满意，我却不得不迁移到其他平台，那将是非常令人遗憾的。
8 个赞
超大主题需要大部分被隐藏——即使它们已关闭和/或已归档，访问超大主题的用户越多，服务器的性能就越差。理想情况下，应删除超大主题，确保任何时刻只有一个处于活动状态？这是我的建议。您拥有的超大主题越多，面临的风险就越大。
如果您愿意投入大量资金解决这个问题，可以大幅超额配置服务器以支持更多超大主题——但这仍会影响所有主题的中位性能。
4 个赞
即使话题已关闭，它仍会产生数据、流量和负载。
请记住，每个用户的阅读位置都会被记录到每个话题中。每篇帖子都可以被点赞，即使话题已关闭，用户仍可与超级话题进行互动，更不用说它可能给搜索结果带来的大量干扰信息了。
2 个赞
但这仍然没有解释为什么超大型主题尤其会引发问题。为什么一个拥有 10,000 篇帖子的主题会比十个各含 1,000 篇帖子的主题更糟糕？在后者情况下，潜在可点赞或搜索的帖子总数相同，但需要追踪的阅读位置和主题数量却是前者的十倍。仅根据你的解释，我会得出拥有更多小型主题的结论反而更糟。因此，肯定还有其他因素在起作用。
4 个赞
因为你是每次只加载一个主题。你可以轻松地逐个加载 10 个各含 1,000 条回复的<此处插入轻量级内容>，但一次性加载 10,000 条回复则要困难得多。
2 个赞
不过，我对具体细节感到好奇。默认情况下，只有特定数量的帖子会在你滚动之前加载，所以这显然不是因为可见帖子的数量。这是由时间线导致的吗？还是由话题摘要导致的？或者仅仅是因为基于话题中帖子总数的各种线性或超线性算法？
我其实并不关心所谓的“巨型话题”，这取决于你如何定义“巨型”。在我最常浏览的社区版块中，帖子最多的话题大约有 3600 条，而排名第 10 的话题仅有 600 条。排名第 25 的话题更是只有 300 条帖子。目前，我更多是从技术角度感到好奇。
6 个赞
这是我编写的一个数据探索器查询，试图回答你的问题。你可以用不同的主题和偏移量来尝试运行它。
-- [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
下面是一个普通大小的主题和一个超大主题的例子：
示例耗时：3.4ms
-> Index Scan using index_posts_on_topic_id_and_sort_order on posts (cost=0.43..1925.22 rows=477 width=8)
示例耗时：353.9ms, 739.6 ms（时间因数据库缓存情况而异）
-> Index Scan using index_posts_on_topic_id_and_sort_order on posts (cost=0.43..605155.88 rows=161255 width=8)
我记得见过超过 750 毫秒的耗时。
以下是中位数和 99 百分位耗时。中位数耗时出人意料地好，但中位数的特性在于，你无法判断在 60% 百分位时情况是否比中位数案例糟糕得多。
这是另一个服务器的数据（它拥有大量类别，这也导致了性能下降，因此如果不考虑巨型主题，这并非完全可比），但你可以看到其中位数性能提高了一倍，而最坏情况也改善了很多：
11 个赞
我也是，只是出于好奇。
我理解，根据以下解释，在超大主题帖中导航可能会影响性能：
然而，我不明白为什么一个或几个超大主题帖会影响论坛其他页面的导航，例如主题列表页面。
通过给服务器添加大量负载。每个巨型话题的负载相当于性能惩罚的 100 倍！请查看您正上方的帖子。
5 个赞
你好，
我目前正将论坛数据导入 Discourse，其中包含大量“巨型主题”：
（帖子尚未全部导入完成！）
由于巨型主题在 Discourse 中运行效果不佳，实际操作中我该如何处理？（我计划未来为社区引入聊天功能，可能是 Discord，但我想知道目前这些主题该如何处置）？
直接删除？
拆分并关闭？
如果选择拆分，每个主题应包含多少条消息？默认的 10000 条上限是否足够，或者您建议调低该数值？
3 个赞
拆分成 1 万个块应该就足够了。
8 个赞
此外，其中大多数看起来还可以。真正的损失是从 1 万开始的，而截图中显示的大部分金额都远低于 1 万。
6 个赞
超级话题的性能影响最新情况如何？我们的新冠疫情后续话题帖子数即将突破 1 万条，我们正在分析近期可能出现的性能放缓问题。
4 个赞
我不知道服务器统计数据的“标准”应该是多少，但我可以分享我们一个拥有大量巨型话题（megatopics）的社区的数据。目前，我们有15个已关闭的话题，帖子数达到10,000条；还有超过50个已开放的话题，每个话题的帖子数都超过2,000条。在任何给定时间，论坛的大部分活动都集中在相对少数几个非常活跃的话题中。
我们目前运行在 DigitalOcean 服务器上，配置为4个虚拟CPU、8 GB内存和160 GB磁盘空间，每月费用为40美元。也许每隔几个月，某些用户会非常短暂地收到“极端负载”的提示。这种情况只发生在有直播活动且大量用户同时发帖时——例如，在长达一两个小时内，单个话题中每分钟平均有多条新帖发布。
除此之外，系统性能一直非常流畅，没有任何问题。我们目前的情况是，在需要升级其他任何组件之前，磁盘空间会首先不足。
6 个赞
这个数量很合理，2000条帖子不算什么，几十个1万+的帖子主题（尤其是已关闭的）应该也没问题。危险情况是当你有很多活跃的超大主题帖时。我会把“很多”定义为超过几十个。
10 个赞
虽然“巨型话题”在 Meta 这里通常不是问题，但它们似乎是许多社区组织讨论的自然方式。换句话说，这些讨论缺乏自然的断点。
Inderes 是一家芬兰公司，为股市提供财务分析。他们最近推出了自己的 Discourse 社区，考虑到其所在区域和细分市场，取得了巨大成功。
讨论主要按股票或投资工具组织，例如 $AAPL 或 $TSLA。如今，在短短两年左右的时间里，许多此类话题的回复量已接近 1 万条。这既是 Discourse 的一个绝妙概念验证（一个从零开始构建的活跃社区），也凸显了“巨型话题”所带来的问题。
4 个赞
至少，你可以按年份将其分段。这在第一帖中已有说明。巨型话题可以维持一段时间，但如果数量过多，最终会导致你的网站崩溃。
（此外，当同一个“话题”中有数万条帖子时，搜索会变得极其困难——基本上你构建的是一个聊天室。）
5 个赞