聊天插件：大规模性能 - 禁用保留和大量 API 使用？

支持
1

我正在探索 Discourse Chat 插件的替代用例，并对其实际性能限制有一些疑问，特别是关于数据保留和大量 API 使用。

为了提供一些背景信息，我们正在寻找一个支持多级回复的评论系统。“Chat”插件中的“threaded replies”功能提供了比标准主题/帖子结构更贴近我们需求的用户体验。因此，我们正在考虑将聊天频道用作持久化的评论线程。

鉴于此用例，我们需要无限期地保留聊天记录。这引出了我们的主要担忧：大规模下的性能。

我们预计的使用量很高：

  • 总消息数： 大约在 100 万到 1000 万条消息之间。
  • 频道数： 大约 150 到 200 个频道。

我们的主要问题是：

  1. 是否可以完全禁用聊天记录保留，或者将其延长以支持提到的消息数量？ 例如，通过将保留期设置为 0 或一个非常大的数字。
  2. API 性能会受到何种影响？ 我们计划大量使用 Chat 插件的 API 来与我们的外部系统集成。我们的主要访问模式将是按**时间顺序（从最新到最旧）**获取主要频道和线程的消息。这种对具有海量历史记录的频道进行频繁 API 轮询是否会造成显著的服务器负载？
  3. 永久存储数百万条聊天消息对服务器和数据库的总体性能影响如何？ 具体来说，这会如何影响：
    • 服务器 CPU 和 RAM 使用情况？
    • 整体网站响应能力？
  4. 在这种负载下，是否存在任何已知的“临界点”或软限制，导致系统性能开始显著下降？

我们理解这是对聊天插件的一种非常规用法，并且禁用保留期并非最佳实践。我们的目标是在承诺采用此方法之前，确定系统在 UI 和 API 方面的架构限制。

来自团队或在大型规模下运行过聊天插件的社区成员的任何见解都将非常有价值。

4 个赞
3

嘿 @Nima1，我可以开始回答其中一些问题：

  • 是否可以完全禁用聊天记录保留，或者增加聊天记录保留以支持提到的消息数量？ 例如，通过将保留期设置为 0 或一个非常大的数字。

是的，这是可能的。您可以将 chat channel retention days 设置为“0”以永久保留消息 — 但考虑到您正在进行的规模，您对性能影响的疑问是正确的。我还要指出，我们目前不支持搜索聊天消息（我们有考虑过，但目前未计划）。这意味着，即使您永久保留消息，考虑到您的高项目使用量，成员可能也无法找到特定消息。

API 性能会受到什么影响？

一般性能影响会是什么？

我不能确定这些问题的答案，让我去咨询一些对聊天功能贡献最多的工程师，看看他们的想法。

我也很想了解您的用例——您愿意分享更多关于您正在努力实现的目标的细节吗？

2 个赞
7

您好 Lindsey，

感谢您的回复以及与工程团队的沟通。我很乐意分享更多关于我们的用例。

我们正在为加密货币爱好者构建一个社区。对于每种主要的加密资产，我们都希望创建一个专门的、持久的频道来进行实时讨论。

我们发现标准的“话题/帖子”模型并不适合此场景，因为：

  1. 节奏与格式： 对话节奏快，由简短的消息、更新和反应组成，这非常适合聊天格式。

  2. 信息流： 我们的用户需要首先看到最新的消息，然后向上滚动查看最近的历史记录，这在聊天中是默认行为。相比之下，“话题”的设计是从最旧到最新的时间顺序阅读。

聊天插件的线程回复和逆时间顺序显示非常符合我们想要创造的用户体验。

我们的主要挑战是规模。因为我们将为每种资产创建一个频道，我们预计需要数百个频道，每个频道可能包含非常长的历史记录。这就是为什么我们对性能限制如此感兴趣。

我们致力于使用 Discourse，因为它强大的审核、用户管理和游戏化功能对建立一个健康的社区至关重要。

期待听到工程师们的想法。再次感谢！

9

感谢您分享您的想法，@Nima1！

与我们的团队交流后，我恐怕无法确定此消息量会对性能产生何种影响——目前我们没有多少用户能以这种规模使用聊天功能，并且您选择托管网站的位置将产生重大影响。

您打算自托管 Discourse 吗？

2 个赞
10

您好，感谢您的快速回复和与团队确认！

回答您的问题：是的，我们是自行托管的。我已经设置好了实例。