谢谢。你很可能为我节省了大量调试和试错的时间。
这种行为的差异让我得出结论：这是某种应用层面的关联问题，源于前端“导致应用崩溃”（前端并非我的专长，后端才是），以及当前操作——发布帖子且人们停留在某个话题上等待其“自动更新”，一分钟内出现数十条消息。
总结一下这句长话：你的结论是，实时讨论的“阻塞”是一个前端问题？
我们的分析尚未深入，但我观察到 CPU 负载远未达到峰值，仅约为 25% 左右。多年来我们曾多次遭遇 CPU 100% 的情况，但上周六的最新事件中并非如此。当时我们只有大约 150 个并发用户。
让我怀疑后端的原因是，我们运行这些游戏聊天已有多年，此前从未见过这种“阻塞”现象。多年来数据库不断膨胀，目前帖子数量已超过 80 万条。
你第一次发现这个问题是什么时候？这是否可能是最近一次重大更新导致的回归问题？我们的网站和性能在春季一直正常，夏季期间用户增长也不大。
Babel 是一个极其低效的插件。因此，如果您正在使用 Babel，体验可能会很不理想，尤其是在大量用户同时活跃的高负载场景下。
我们现在的待办事项列表中已有一项任务，旨在优化性能，以应对 1000 人同时查看同一主题且其中一人发帖的情况。
按当前设计，我们会向所有 1000 人发布“嗨，该主题有新帖子”，随后这 1000 人（大部分几乎同时）涌向服务器询问……“嘿，你提到的这个新主题是什么？”
我们将考虑以更合理的方式对该场景进行最低限度的速率限制，以避免客户端对服务器造成过大压力。此外，针对这种极端情况，我们还有许多其他优化空间。
好消息，此事已引起您的关注。您能否确认自去年春季以来是否出现了回归问题？
我们当地的冰球联赛通常于10月1日开始比赛。这意味着我们的网站每周都可能产生真实的流量高峰，如果您需要或希望研究系统在真实（非模拟）环境下的表现，这将是一个很好的机会。
如有兴趣，请通过私信联系。我们很乐意提供支持。
从用户体验的角度来看，即使系统开始出现卡顿，最终用户也应能明确知晓讨论仍在进行中。这有助于避免不必要的浏览器刷新。
不，很遗憾我无法确认这一点，这个问题一直存在。
第一场游戏刚刚结束，我们确实遇到了三月份未曾遇到的问题。原因尚不清楚。
游戏聊天在前端出现卡顿，而服务器负载应远低于 100%。
我们的用户 Ole 在卡顿期间发现了一些 429 服务器响应，但我无法确定这是否“正常”，因为我们在比赛期间此前从未进行过此类检查。
@iceman，你在你的网站上遇到过这种情况吗？
我在调查一个完全无关的“500”错误时也遇到过一次这种情况 
服务器当时并不繁忙，但我正在折腾前端的 nginx 配置（http2）。
你说的“游戏聊天”是指“同一话题下有大量用户同时在线”吗？
确实如此。在短短几个小时内，出现了大约 900 条带有反动倾向的回复。@ljpp 掌握更精确的用户数量，但我们可以确定，在比赛期间，任何时候都有数百名用户正在浏览该话题。
奇怪的是，这并非影响所有用户。例如，我在任何设备上都没有遇到任何问题。但根据报告，受影响范围确实相当广泛。
这个问题并不明显，尤其是如果你没有密切注意的话。
首先会出现30到60秒的静默期，没有任何回复。看起来一切正常，只是没有动静。你甚至可以自己发帖。然后突然之间，你会瞬间收到几十条消息，这时你才意识到自己已经落后了。我在 iOS 的 Safari 和 Android 的 Chrome 上都遇到过这种情况。
我们的实时游戏聊天室虽然繁忙，但并非极端情况。昨天我们在大约3小时内收到了972条消息。
下一场游戏聊天将于今天14:00（UTC）进行。由于疫情的影响，我预计消息数量会类似，尽管这是一场主场比赛。
我同意 @pfaffman 关于此问题的帖子。
你难道不是在试图将聊天场景强加于论坛平台吗？
为什么不将 Mattermost 或 Discord 等聊天服务集成到你的 Discourse 网站界面中，而让论坛专注于游戏内的讨论呢？
你可以寻找其他方式，在论坛主题中涵盖游戏内容，例如赛前或赛后讨论。这类场景的使用负载可能较低，但或许包含许多用户日后可能希望检索的有用总结信息。
此外，我也看不出将大量即兴聊天内容存储于论坛中的好处。会有人再次阅读这些内容吗？它们真的有用吗？
嗯，他用“聊天”这个词来描述这个功能，但根据用户的说法，他的 Discourse 设置无法处理“在约 3 小时内发布 972 条帖子”的情况……依我看，这本来应该能处理，哪怕是一个简单的 phpBB 论坛也能在 3 小时内处理比这多好几倍的帖子。
所以每10秒发1条帖子？单看这一点似乎还算合理。但如果你让一个主题帖达到1000条回复，并且有数百名用户参与，再加上发帖量出现高峰，那挑战就不言而喻了！
但真正的罪魁祸首或瓶颈究竟在哪里？是参与的用户数量，还是每 10 秒 1 帖的频率，亦或是将变更后的内容渲染给（过多）非匿名/匿名用户，还是为大量已登录用户提供服务所需的连接数量？
如果只有 2 个用户在相同的时间段内在同一主题中发布相同数量的帖子，他是否也会遇到同样的问题？
即使只有 972 个已登录用户在该主题中各发布一条帖子，Discourse 是否也无法处理这种情况？如果是，原因是什么？Discourse 是否仅适用于用户规模很小、同时在线登录用户数较少的社区？
我之所以有此疑问，是因为我们目前已有高达 400 个同时在线的登录用户，每天可产生多达 3000 条帖子，但迄今为止尚未出现任何问题。
您显然需要考虑服务器规格和运行的独角兽数量，否则这些压力测试场景的结果意义不大。
Blenderartists（@bartv）据我所知，拥有一台 64GB 内存的服务器，并运行着大约一打独角兽？这可真是一头猛兽 
当然，我们目前在 DigitalOcean 上仅使用 8 GB 内存和 4 个 vCPU，目前没有遇到任何问题。因此，如果解决这个问题的方法仅仅是增加资源（内存和 CPU），我完全同意。自从重新上线 Discourse 以来，我们在某篇病毒式传播的帖子中曾达到约 2000 名并发访问者，当时负载略高于 1，CPU 使用率在 60% 到 70% 之间。而在平均约 200 到 250 名并发在线用户的情况下，CPU 使用率目前仅在 15% 到 20% 左右。
没错 很乐意分享数据，尽管我们不把 Discourse 当作聊天工具，也从未遇到过如此剧烈的流量高峰。
你或许可以这样认为，但我非常不赞同将对话分散到两个平台的想法。实时性实际上是 Discourse 的杀手级功能之一，深受终端用户喜爱。我们的游戏内对话非常受欢迎，是社区文化的重要组成部分。
请注意，我们已经运行这些活动四年了，这是新出现的问题。在此之前，数百场游戏都运行顺利，并未出现任何“强加”的情况。
我们的一位资深成员提出了一个理论——我们是否触及了 Discourse 的全局限制，或者 CloudFlare 可能产生了影响。
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE：每分钟每个 IP 的请求数（默认为 200）
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS：每 10 秒每个 IP 的请求数（默认为 50）
下一场游戏将在 1 小时后开始，我们将尝试禁用 CloudFlare 缓存进行测试。
请注意，我们也已经使用 CloudFlare 四年了，尽管这里通常不推荐这样做。期间只出现过一两次问题，其中一个是 Brotli 压缩，另一个是模板未更新。
不行，CF 并非根本原因。在禁用缓存的情况下问题依然复现。报告了 429 错误。
有人有想法吗？
是的，我理解你的担忧。我不希望一些有趣的见解因聊天而丢失记录。这确实是一个棘手的两难困境。