「極度の負荷により、このページは一時的にログアウトしたユーザーと同じ表示になっています」
私はバスケットボールの試合中にライブスレッドを掲載するウェブサイトを運営しており、試合中（ピーク時の活動）にサーバーが過負荷となり、このメッセージが表示される問題に直面しています。
この問題を解決する最善の方法を特定する方法はありますか？それはストレージの速度、メモリ、CPU のどちらが原因でしょうか？サーバーを強化する以外の対策はありますか？もしこの期間中に強化する場合、何を強化すべきでしょうか？
フォーラムの利用者を減らすのはどうでしょうか？さらに良いのは、ゲーム中に集中して利用するのではなく、利用時間を分散させることです。
しかし、それらは役に立たないでしょう。ゲームの開催時間がわかっているなら、ゲーム中だけサーバーを強化するか、ゲーム中はロードバランサーの背後で複数のサーバーを運用することもできます。
ピーク時のトラフィックに対応するために、Web プロセス（Unicorn ワーカー）の数を増やすには、より多くのコアと高速な CPU、およびより多くの RAM が必要です。
これは @sam が積極的に取り組んでいる分野です。パフォーマンスの観点から見ると、Discourse の新しいバージョンではこの分野で後退しているように見えます。
とはいえ、実際の解決策は、数百人が同時にリアルタイムな対話を必要とする場合は、ライブチャットツールを使用することです。ただし、Twitch や YouTube のストリームのように、チャットが非常に速くスクロールして誰も実際には何も見られない場合、チャットが「有用」である理由と方法については、引き続き疑問に思っています。
このスレッドは問題を非常にうまく説明しています。
問題が発生する前の、試合中のサッカーフォーラムでの私の経験は以下の通りです。
Digital Ocean
1 CPU 1 GB = チャットのような状況で 30〜40 人のユーザー
2 CPU 2 GB = チャットのような状況で 70〜80 人のユーザー
4 CPU 8 GB = 2 時間で 120 人のユーザーと 1000 件の投稿でも問題なし。限界には達しませんでした。
Hetzner（ミラーリングサイト）での経験：
私の経験では：
3 CPU（CPX 21 AMD チップ）4 GB = 20 人のユーザーで苦労
2 CPU（Intel）8 GB = 20 人のユーザーで問題なし
より多くのユーザーでのテストは行いませんでした。
重要なのは CPU と RAM を増強することです。それに加えて、app.yml ファイルも編集してください。
ここで unicorns の数を増やし、db_shared_buffers も変更してください。
スポーツフォーラムの場合、試合のライブテキスト更新に近づきます。人々はそれほどチャットをしているわけではありません（特にハーフタイムなど、ある程度は行われますが）、むしろファン同士からライブテキストの解説を受けています。
多くの人が、ライブテキストを読むためにフォーラムにログインします。主要な試合イベントに対するキーパーソンたちの考えや意見を見るためです。面白い反応から真面目な分析まで様々です。
試合を見逃した場合でも、人々はイベントごとの解説を読むためにログインします。仕事中の人には大変便利です ;)。新聞やテレビ局のテキスト解説よりも、より個人的でバイアスがかかっています。
その通りです。アップグレードされたサーバーで discourse-setup を実行すれば、それが行われます。
おっしゃる通りです。@sam @eviltrout と私はこの件を詳しく検討しています。「数百人のユーザーが同時に同じトピックにログインして閲覧している」という状況は、Discourse がますます普及するにつれて、最近よく見られるようになってきています。
この場合、新しい行動様式を呼び起こす必要があるかもしれません。トピックの UI には、何らかの形で「ファストレーン」を示すサインが表示されるべきでしょう… 
ここで覚えておくべき重要な点は、「チャット」の実装では、実際のコンテンツを購読者にブロードキャストすることが一般的だということです。
Discourse では、この単純な実装を複雑にする非常に複雑なパイプラインが存在し、結果として大量のトラフィックが発生します。
- ユーザーが返信を投稿する
- トピックを閲覧しているすべてのユーザーが、ブロードキャストを通じて新しいコンテンツがあることを検知する
- すべてのユーザーがサーバーに投稿コンテンツを要求する（100 人の閲覧者 = 100 回のリクエスト）
- 画像の取得・最適化を行う
- トピックを閲覧しているすべてのユーザーが、ブロードキャストを通じて新しいコンテンツがあることを検知する
- すべてのユーザーがサーバーに投稿コンテンツを要求する（100 人の閲覧者 = 100 回のリクエスト）
（各種最適化、レート制限、再試行などを行っていますが、概ねこのような流れです）
これらのリクエストはすべて、ユーザーが投稿を閲覧する権限を持っているかなどを確認するためのセキュリティパイプラインを経由する必要があります。
もしコンテンツが比較的短く、セキュリティ処理を「ファストレーン」向けにより軽量な方法で実現できるのであれば、チャットメッセージをブロードキャスト経由で配信することが可能になります。これによりパフォーマンスが劇的に向上し、この設計であれば、低スペックな 2GB メモリの DigitalOcean ドロップレット 1 台で 1 万人のユーザーを処理できるかもしれません。
セキュリティは非常に複雑です。キャッシュの無効化の問題もあり、キャッシュ管理もまた複雑です。
したがって、はい、私たちはこの問題について真剣に検討しています。しかし現状では…
1 つのトピックに多数のログインユーザーが同時にアクセスし、かつそのトピックに大量の新しいコンテンツが投稿される場合、サーバー費用が膨大になります。
それは素晴らしいですね！
正直なところ、私は「危険なほどに知識がある」レベルです。私は遊びながら（そして壊しながら）学ぶタイプです。このプラットフォームを作るための素晴らしい努力に心から感謝しています。12ヶ月前に最初のフォーラムを作成したときは、Vanilla、MyBB、SMF、Flarumなど、12もの異なるバージョンを試しました。その中でDiscourseが最も優れていました。
最大の利点の一つは、活発な開発です。コミュニティの声を聞き、絶えず改善を重ねている様子を見るのは素晴らしいことです。
これに関する推奨設定はありますか？
皆さん、私のサイトは後退しているようです。DOパッケージ（8GB、4CPU）は同じですが、60〜70ユーザーが1000件の投稿をしていると、サイトが苦戦し始めています。
2点質問があります。
-
極端な負荷メッセージを削除することは可能ですか？ ユーザーに役立つというよりも、ユーザーをより不安にさせるようです。
-
大量のユーザーに対処する進捗はありますか？
その間、ユニコーンの変更やプラグインの無効化などを検討して、リソースを解放するのに役立てます。
インストール後にサイズを変更した場合、discourse-setup を再度実行しましたか、それとも設定を手動で変更しましたか？
手動で実行しましたが、discourse setup を実行すべきでしたか？
編集を行った場合、再構築が必要です（destroy/startで可能かどうかは不明です）。
確認のため、YAMLを編集した後、単に ./launcher rebuild app を実行しただけで、理解に誤りはありませんか？
代わりに ./discourse-setup を試す価値はありますか？
（前述の通り、私には危険なほどの知識しかありません 
）
問題ないはずです。Discourse-setup がメモリ設定を変更します。もしご自身で行ったのであれば、問題ないはずです。
念のため、また興味本位で伺いますが、スワップは設定されていますか？
2GBのスワップファイルがありますが、8GBのスワップファイルを推奨しますか？（RAMの量に合わせますか？）
ディスク容量に余裕があれば、スワップ領域を増やしても問題ありません。free コマンドでメモリの使用状況とスワップの使用量を確認できます。