昨天，我们刚刚为活跃发帖且用户众多的站点实现了一项重大的性能提升，这应该会对您的站点大有裨益。
很好，我们会查看并可能进行测试。
嗯，每场比赛都是个案。在当前的疫情环境下（场馆空场）以及赛程近乎随机的情况下，观众的行为难以预测，也无法与历史数据进行比较。
仅凭这一场比赛，我无法断言此次变更带来了显著改善。
第一节比赛期间情况平静且正常，但第二节发生的事件导致消息量激增，潜水用户数量增加。约 60% 的用户表示遇到了卡顿现象。
在双服务器架构中，只有 web_only 服务器报告了高 CPU 使用率和平均负载。
极端负载/只读模式并未被触发，这是好事，因为该模式带来的用户体验最为糟糕。总体而言，观众已迅速学会访问首页，稍后返回以继续讨论——但这反而增加了服务器负载。如果能让最终用户以某种方式得知自己正在被限流，他们就更有可能愿意等待一分钟。
私人对话进展报告：通过将 DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS 设置为 4，体验得到了改善。我们正计划进行一些核心变更，以优化消息总线速率限制行为。
鉴于我们与 @ljpp 的情况有一些相似之处，尽管程度要轻得多（几乎仅限于比赛结束前后约 5 分钟的时间段），我想知道是否可以对触发“高负载”消息以及用户开始被“踢出”主题的阈值进行任何调整……因为这总是发生在同一个主题上，即比赛主题。
此外，在同样的上下文中，我们还更罕见地遇到 502 错误消息（纯粹的 Nginx 消息）。我怀疑 Nginx 中可能有一些配置可以通过调整来受益，我知道这并非你们的职责，但我非常乐意听取任何好的建议 
。
请澄清一下——您遇到的是冻结（主题未更新新帖子），还是出现了“极端负载”错误提示？
本线程中有一些优化方案可改善冻结问题，但它们也会增加系统负载，因此您更可能遇到“极端负载”的情况。
在这些我报告过的情况下，我们偶尔会遇到主题冻结的问题。但一旦发生这种情况，系统也会显示极端负载的警告。因此，我无法确定具体是哪种情况。
我们并不介意极端负载，只要它不会将用户踢出主题或中断新帖的更新。在这种情况下，我们反而更希望系统能缓慢加载内容（例如，每个用户阅读或发帖时加载指示器可以旋转15秒），我们宁愿这样，也不愿面对主题冻结或用户被强制退出的情况。
我不得不表示赞同。极端负载 的用户体验对最终用户来说令人困惑。
- 您有多少并发用户？
- 使用什么样的硬件？
- 能否提供论坛统计数据的链接？
既然我们现在使用的是 CDCK SaaS 平台，我只能从用户体验（UX）的角度来观察这个问题。
过去几周，我们的游戏话题一直非常火爆。随着平台的切换，“冻结”现象已基本消失，但话题更新方式存在一些波动，这可能仍会让部分用户感到困惑。不过，大多数（约 90%）用户已不再抱怨，而是专注于游戏本身，这是一个积极的信号。
然而，有一个场景我可以以较高的置信度（同样约为 90%）复现：当游戏话题处于后台标签页（Android）或屏幕锁定状态下时，平台在恢复会话时偶尔会出现问题。当我回到这个活跃话题时（通常是因为游戏中发生了有趣的事件），话题视图有时并未更新。我能看到话题底部的用户头像在闪烁，但没有新帖子出现。此时需要刷新浏览器才能完全恢复。
复现该问题的步骤并不简单，需要满足以下条件：
- 一个活跃的话题
- 游戏中有激烈的操作 → 话题热度上升
- 将话题置于锁定屏幕下或浏览器后台标签页中
我们也遇到过这个问题。
还有另一个情况：当跳转到第一条未读帖子时，可能会重复这种行为几次（多次跳转到同一个“未读帖子”，尽管每次未读帖子的位置本应发生变化）。
举例说明：
- 我跳转到第一条未读帖子
- 滚动并阅读了 100 条未读帖子
- 然后前往另一个话题或首页…
- 大约一分钟后，大约有 30 条新的未读帖子，但当我点击图标时，我又被带回了第 1 步的位置（意味着向后跳了 130 条帖子，而不仅仅是新的 30 条未读帖子）。
不过，再次强调，这种情况仅发生在非常非常繁忙的话题中，且只在所有用户在同一话题中同时刷新和发帖的高峰时段持续几分钟。有点烦人，但目前还不是无法接受的问题。
我认为这算是一种成功。
你能在 meta 上提供一个复现示例吗？可能不行，因为这需要大量活跃用户同时停留在同一主题中？
我目前的想法是，我们应该构建一个实时聊天功能，并仅在以下情况发生时即时实例化：
- 有大量用户
- 处于同一主题中
- 且在同一时间
然后，且只有在这种情况下，才实例化一个实时聊天框覆盖层，并强烈引导用户使用该功能而非回复帖子，甚至可能禁用直接回复该主题的功能，并显示：
📢 嘿，看来你**真正想要**的是一个聊天室……就在这里，玩得开心！💬
是啊，我懂你的意思，但这种场合太少了，我觉得不值得花这个功夫。我们通常每周有一到两次这样的比赛，而且大多集中在比赛结束后的5分钟内。不过，我其实已经想过好几次了（要是能在足球比赛那90分钟期间有个临时聊天室功能或切换机制就好了）。
不过，改天我会试着通过录屏来复现一下。
随着季后赛比赛开始，我们的实例出现了一些 429 错误。@staff 应该能在我们最近 3.5 小时的日志中看到部分记录，而在决胜球打入时（我打字时比赛正进入第二个加时赛）预计还会有更多。
无论如何，如果您仍在进行日志记录和追踪，那么机会已经不多了，因为总决赛及随后的休赛期即将来临。
我只是想在此帖中加上我的名字，以便跟进讨论。我们是一个新的体操论坛。昨晚在美国奥运选拔赛期间，我们遇到了上述问题以及“卡顿”现象。相关帖子如下：
https://gymnaverse.com/t/us-wag-olympic-trials-night-2-live-discussion/1092
昨晚我们出现了4个“独角兽”（异常高负载实例）。
我们在 Digital Ocean 将服务器调整为 4 个 Intel vCPU 和 8 GB 内存，并进行了以下配置：
unicorn_workers: 8
db_shared_buffers: “2GB”
我们预计奥运会期间流量将大幅增加。除了上述措施，还有哪些方法可以优化服务器以应对比赛期间类似“聊天”的高并发流量？
如果您在 Discourse 中作为聊天工具使用，且单个主题下有成百上千的用户，同时这是一个限时活动，我建议您暂时提升一下服务器配置。
Digital Ocean 中较大的 Premium AMD Droplet 实例，用于为期 16 天的奥运会活动，费用为 54.85 美元，对于您这样规模的社区来说应该绰绰有余。
我的 app.yml 中没有这些行。我只需要添加它们吗？
是的，请将它们添加到 env 部分。
如果此事仍在工作人员的监控范围内，我们的首发将于今晚 18:30（UTC+3）进行，明天同一时间也将再次进行。
在经历了两个因新冠疫情而受挫的赛季后，大家期待已久，因此我预计 tappara.co 网站将面临巨大的流量高峰。
@ljpp 你目前的情况如何？Redis 6 对你有帮助吗？
我们现已迁移至 CDCK SaaS 平台，因此已提前告知相关工作人员。我们在此方面充当了测试平台的角色。