直近、単一のページに約1,500人の同時接続ユーザー（ほとんどが匿名）が訪れるピークトラフィックが発生しました。
その結果、フォーラムは高負荷を警告するモードに切り替わり、すべてのメンバーに警告が表示されました。
使用環境：
CPU最適化のDigital Ocean Droplet
専用CPU: 4 vCPU
RAM: 8 GB
Unicorn ワーカー数: 10
現在のRAMとCPUの使用率は約50%のみですが、このような匿名ユーザーによるピークトラフィック時にUnicornワーカー数を増やすことで改善が見込めるでしょうか？
はい、ここで最初のステップはユニコーンの数を増やすことです。
ワーカー数を24に増やしましたが、変化はありません（「極度の負荷のため、このページは現在、ログインしていないユーザーが閲覧するのと同様に、すべてのユーザーに一時的に表示されています」と表示され続けます）。先ほど、同様の同時接続者数のピーク（99%が匿名）が発生しました：
@sam は最近これに多くの時間を費やされており、何かコメントがあるかもしれませんね？
@sam 匿名ユーザーからのピークトラフィック（例えば、単一のトピックがソーシャルメディアでバズった場合など）をさらに最適化する方法について、アイデアはありますか？上記の両ケースにおいて、メモリとCPUにはまだ余裕があります（Digital Oceanのレポートによると）。負荷が4に達していないにもかかわらず、ワーカー数を3倍に増やしたにも関わらず、フォーラムは「極度の負荷」モードになります。
ボトルネックがどこにあるか把握するために、いくつかのデータを収集する必要があります。
DOのデータモニターは感度が十分でなく、やや誤解を招くものだと考えられます。HetznerとDigital Oceanで極端な負荷をかけた実験を行いました。Hetznerでは「極端な負荷」のメッセージが表示された際、120%まで急上昇する短く鋭いピークが発生しました。
それは約1秒間続き、その後40〜50%のレベルまで低下しました。
同じ現象をDigital Oceanでも再現しましたが、記憶ではCPU使用率は50%を超えることはなかったようです（ただし、X軸を秒単位に変更することはできませんでした）。
私の推測では、DOのCPUレベルは5秒または15秒間の平均値を示しているのでしょう。そのため、短く鋭いピークは表示されないのだと思います。
より深く調査するには、Prometheus エクスプローラーのレポートが必要です。
メモリと CPU が十分であれば、 Unicorn ワーカーをさらに追加することで、これらのピーク時にもスケールアップできます。ただし、メモリのスワップが発生しないようにしてください。パフォーマンスが大幅に低下してしまいます。
そのような場合、その単一のトピックページを一時的にキャッシュして、バックエンドにアクセスすることなく静的に配信できるはずです。Discourse がその機能を持っているか（つまり、負荷時や匿名ユーザーへのコンテンツ配信時にキャッシュ制御ヘッダーを設定できるか）、DO 環境に適切なキャッシュプロキシがチェーンに含まれているかはわかりませんが、もし私の認識が間違っていなければ、あるいはすでに実装されていなければ、検討に値する開発アイデアかもしれません。
もしかすると @sam さんはすでにこのことを考えているか、実装しているか、あるいはなぜそれが悪いアイデアなのかをご存知かもしれません！
それはすでにトピックごとに測定された負荷の下で動的に発生します。まさにこれが
で言及されている内容です。ただし、このモードは読み取り専用のため、実際の会話を行うことはできません。
はい、ただし私の提案としては、匿名ユーザーのみをキャッシュページに誘導し、短いタイムアウト（60 秒程度）を設定して負荷を軽減し、サイト残部が読み書きモードを維持できるようにすることを推奨します。
それは素晴らしいですね。現在、20万人以上のユーザーがいる Telegram チャンネルでトピックを特集すると、Discourse サイト全体が約 1 時間「読み取り専用」モードになります。ログインユーザーは約 50 名で（トラフィックの 99% は匿名です）。
これはすでに実現されています。匿名ユーザーのトピック一覧ページやトピックページでは、Redis に直接非常に積極的なキャッシングを適用しており、タイムアウトは60秒です。
ボトルネックを特定するために Prometheus を起動してみますが、おそらく @Alec が指摘した通り、DO の監視が遅れているのだと思います。もしそうなら、より大きなマシンを導入するのが次の一手だと考えられますが？
