我们刚刚经历了约 1,500 名并发用户（主要是匿名用户）访问单个页面的流量高峰。
随后论坛进入了高负载模式，并向所有成员显示了相关警告。
配置如下：
CPU 优化的 Digital Ocean Droplet
专用 CPU：4 vCPU
内存：8 GB
Unicorn 工作进程数：10
鉴于目前仅使用了约 50% 的内存和 CPU，针对此类来自匿名访问者的峰值流量，增加 Unicorn 工作进程数是否会有帮助？
是的，增加独角兽企业数量是这里的第一步。
我知道 @sam 最近在这上面花了很多时间，或许有什么评论？
@sam 对于如何进一步优化以应对来自匿名用户的峰值流量（例如，某个单一话题在社交媒体上病毒式传播），有什么建议吗？在上述两种情况下，根据 Digital Ocean 的监控，内存和 CPU 仍有充足余量，负载甚至未达到 4，但论坛仍进入“极端负载”模式，尽管我们已将工作进程数量增加了两倍。
您需要收集一些数据，以便我们了解瓶颈所在。
我认为 DigitalOcean 的数据监控不够灵敏，且有一定误导性。我在 Hetzner 和 DigitalOcean 上进行了极端负载测试。在 Hetzner 上，当出现极端负载提示时，会出现一个短暂而尖锐的峰值，瞬间飙升至 120%。
这个峰值大约持续了一秒，随后便回落到 40% 至 50% 的水平。
我在 DigitalOcean 上复现了同样的情况，根据记忆，其 CPU 使用率似乎从未超过 50%（而且无法将 X 轴调整到秒级精度）。
我猜测 DigitalOcean 的 CPU 指标可能是 5 秒或 15 秒的平均值，因此无法观察到那些短暂而尖锐的峰值。
我们需要 Prometheus 导出器报告才能进行更深入的分析。
如果您有足够的内存和 CPU 资源，可以随时增加 Unicorn 工作进程数量，以应对这些流量高峰。但请避免发生内存交换（swap），否则性能会大幅下降。
看起来在这种情况下，该单一话题页面应该能够在短时间内被缓存并静态提供服务，而无需访问后端。我不知道 Discourse 是否能做到这一点（即在负载较高时为匿名用户设置缓存控制头），也不确定 DigitalOcean 的配置中是否包含一个功能强大的缓存代理。但如果我的理解没有完全错误，且该功能尚未实现，那么这可能是一个值得考虑的优化思路。
也许 @sam 已经考虑过或实施过这个方案，或者知道为什么这是一个糟糕的主意！
这已经在按主题基础上的实测负载下动态发生，这正是：
所指的。不过，该模式是只读的，因此人们无法在此模式下进行实际对话。
是的，但我的建议是将匿名用户引导至一个带有短暂超时（60秒？）的缓存页面，以减轻其负载，希望这样能让网站其余部分继续以读写模式运行。
这太棒了。目前，如果我们在拥有 20 多万用户的 Telegram 频道上推荐某个话题，整个 Discourse 站点会进入“只读”模式近一个小时。尽管登录用户仅约 50 人（99% 为匿名流量）。
这已经实现了，我们在主题列表页和主题页对匿名用户直接在 Redis 中实施了激进的缓存策略，超时时间为 60 秒。
我会尝试运行 Prometheus 以找出瓶颈，但正如 @Alec 所提到的，问题可能出在 DigitalOcean 的监控延迟上。如果是这种情况，我猜升级更大的机器是解决之道？