使用这些设置后，用户体验更好。是的，我在 Chrome 检查器中记录到了几次“阻塞”和大量 429 错误。CPU 负载较低。但话说回来，那是一场相对平静的家庭游戏（许多活跃成员都在现场，没有在聊天）。
我无法具体指出需要调整哪些参数，但根据我相当主观的经验：
为了排除问题，我将服务器升级到了 8 个 vCore 和 32GB 内存。我将数据库缓冲区设置为 16GB，Unicorn 进程数设置为 16。其他调整已恢复默认。
不幸的是，这次升级效果甚微。即使是中等活跃度的讨论，也频繁出现卡顿。
现在的性能令人失望。我想我需要开始关注 Prometheus 等监控工具了。我有 95% 的把握认为，自 v2.3 版本以来，软件的性能严重倒退。
@Iceman 兄弟在九月份的评论基本被忽视了。他报告称，无论他投入什么硬件，卡顿问题都会发生？
我怀疑您可能遇到了 Redis 瓶颈，但正如我多次强调的，只有收集相关统计数据才能确认。否则，我们无异于在搞占星术。
如果我的怀疑属实，这也解释了为什么增加更多低速核心和内存对解决问题毫无帮助。由于 Redis 是单线程的，您只能通过提升核心性能来实现扩展。
我们将在本月底随 2.6 版本的最终发布推出新镜像，其中包含 Redis 6 以及新的 app.yml 变量，以便充分利用这些资源。如果您想提前测试，请告诉我，我可以为您提供相关操作指南。
刚在一个已关闭的话题中注意到这个问题。@codinghorror - 这是不正确的。在高负载情况下，最终用户实际遇到的是：
但实际上用户并未真正被注销。通常，当用户返回到活跃话题时，网站会像往常一样正常运行。
再次强调，我们没有任何客户报告此类行为（在成千上万的客户中，其中许多网站的访问量远高于您的网站）。因此，现阶段继续讨论基本没有意义——我们无法了解您那边可能存在的任何特殊配置问题或硬件性能异常。
希望未来情况会有所改善，我们将能更清楚地洞察实际问题的根源。
我只是在报告高负载情况下的实际 UI/UX 表现，仅此而已。
其行为应该是：将他们保留在话题页面，并展示未登录视图，而不是跳转到首页。
你说得很可能对。问题确实在 Redis。新的基础镜像有所改善，但现在我们已超出服务器的承载能力。
也许吧，但实际情况并非如此。我刚刚才复现了这个问题。
嗯，至少这个问题有已知的解决方案：
解决方案：编写更精简、更高效的代码 
那么，如果 Redis 是瓶颈，你将如何进行水平扩展呢？
我仍然想不通自从上个赛季以来到底发生了什么变化。我看不到明显的有机增长，游戏聊天的热度也没有显著提升。然而，我们的服务能力却急剧下降，即使在最平静的游戏中也出现了拥塞。
在你无法收集你历史 Discourse 实例的指标，并将其与你在当前安装中收集的指标进行对比（同时保持完全相同的硬件）之前，这仍将是一个谜。
整个差异可能在于：你的 VPS 提供商将你从一台物理机器迁移到了另一台，或者你遇到了一个“吵闹的邻居”，亦或你的 VPS 现在运行的平均共托管服务数量从 13 个变成了 17 个。
请不要猜测将问题推给 VPS 提供商。UpCloud 是市场上最好的服务商之一，他们已经检查过自身端是否存在任何异常情况。他们在我们的网站上投放广告，如果网站出现卡顿，对公关形象非常不利 
不过，我们并没有历史数据，而且说实话，之前我一直没有特别关注，因为一切运行正常，直到八月份首次举办展览比赛。当然，得益于新冠疫情，人类的行为模式已经发生了变化，谁知道还有没有其他因素。不过，我在我们网站或服务器的指标中并没有看到相关迹象。
但这确实是极好的测试素材。我已经向 @riking 提供了一些截图，展示了服务器过载触发时会发生什么。我想你们平时很少见到这种情况。
请注意，没有人不同意您的观点——我们只是想指出，当医生只能通过互联网上的视频摄像头来观察患者时，他们在诊断患者方面所能做的努力是有限的。
只是想说明，这正是我首次搭建自己的站点时遇到的情况（所以并非您站点独有的问题）。
这是我当时发布的关于此问题的讨论帖：
这也促使我跳到了此处列出的不同 CPU/内存选项：
遗憾的是，由于我换了新工作，尚未有机会按描述从 Digital Ocean 正式迁移到 Hetzner。但本月一旦有机会，我会立即着手处理。
关于最终用户被踢出讨论串，或仍停留在讨论串中（但显示已登出消息）的体验，似乎确实与负载相关（进球后更多用户被重定向至站点首页）。
我的技术知识不足以提供具体帮助，但认为提供这样一个案例或许会有所助益：一个拥有类似聊天高峰行为的体育网站也遇到了类似问题。而我的站点（规模较小且较新）是通过进一步升级服务器解决的。
如果您希望拥有数据以辅助决策，从而诊断未来的问题，可以安装 Discourse 的 Prometheus 导出器插件。
简单更新一下：
尽管如此，我们仍频繁触发各种 429 限流。不过，“高负载系统模式”并未被激活。
由于新冠疫情，冰球赛季已被迫中断，目前他们正在没有观众的情况下进行几场随机比赛。既然我们在 UpCloud.com 上拥有托管积分，我们正利用现有资源努力改善体验。目前 web_only 服务运行在 6 核 vCore 16GB 配置，数据服务运行在 4 核 vCore 8GB 配置，独角兽节点已扩展至 18 个。
我们再次禁用了速率限制器…
DISCOURSE_MAX_REQS_PER_IP_MODE : none
…这有所帮助，但我们仍然在 POLL 请求中收到 429 错误，导致最终用户出现长时间延迟或冻结。我们将继续调整，增加 DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS 的值。
但在进行此调整之前，想向 @sam 或工作人员提问：
是否有环境变量可以提高 极端负载 - 只读模式 限制器的阈值，或者是否可以完全禁用它？
这应该是不必要的。我们很乐意为您托管，以便查明为何在您流量如此低的情况下，系统仍会反复触发该限制。
也许如此，但我们希望稍微减少对服务器的保护，因为自然发生的活动峰值非常短暂，通常在一分钟左右就会稳定下来。因此，将阈值稍微调高一点可能会改善用户体验，同时等待迁移。
由于疫情（COVID）的影响，游戏赛事一直稀少，因此我们几乎没有机会对此进行测量和调试。
我们发现，即使我们升级了硬件资源（6+4 个虚拟核心和 16+8GB 内存），即便是适度活跃的用户群也能引发 429 错误（请求过多）。我们在 U20 世界杯赛事中观察到了这一现象，当时聊天室吸引了约 50% 的常规游戏观众。
经过测量、试验和反复调整，我们确定了以下优化参数：
DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.4
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: 400
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: 100这些调整似乎消除了 80% 的 429 错误，从而为大多数用户提供了相对流畅的体验。
下一步本应是采购不同类型的硬件资源，例如使用专为单线程速度优化的独立服务器，或切换到提供拥有海量虚拟核心计划的 VPS 提供商。但对我们而言，下一步是与 Discourse 托管团队合作，正如 @sam 之前所提示的那样。
希望这些优化对 @iceman、@alec 或其他任何人有所帮助。请务必密切关注 CPU 使用率和队列情况。此外，我从这次实践中还学到：使用 2 个容器远远优于 1 个——优化可以近乎零停机时间实施，且硬件资源能更细粒度地利用。
我仍然欢迎任何新的优化方案或发现，以帮助提升由现实世界事件驱动的快节奏讨论的性能和用户体验。