私の経験上、これは現在のどのアプローチでも直接解決されるものではなく、線形な解決策も存在しません。実際、別々のマシンに分離しても、この問題に対する即効性のある解決策にはなりません。
また、大きなイベント（@ljpp が言ったようなゲームなど）が発生すると、激しい遅延や「サイトが非常に混雑しているため、ログインしていないユーザーとして表示されています」というメッセージが発生し、そのトピック内のユーザーだけでなく、サイト全体が影響を受けます。
そのため、私は「分離されたセットアップ」と「大型マシン」の 2 つのアプローチを試しましたが、どちらも同様の問題が発生します。私のインスタンスは Prometheus で監視され、ログは Grafana などで確認可能であり、ハードウェアやコンテナのパフォーマンスを非常に詳細に制御できます。しかし、何を行ってもこの問題は必ず発生することを確認しています。
大型マシンを背後に配置しても、わずかに遅延を遅らせることはできるかもしれませんが、エラーやセッションの切断が発生し、マシン自体はディスク、CPU、RAM のいずれもほとんど使用されません。これは「デフォルトのインストール」と「2 つのコンテナ」のインストールの両方で起こります。
異なるマシンを使用する場合でも、マシンの種類が同じであるか、一方が「CPU 最適化」で他方が「ディスク最適化」であるかなどに関わらず、問題は同じです。さらに、異なるマシン間の接続に失敗する可能性という追加のレイヤーも考慮する必要があります。この接続には遅延が避けられませんが、遅延の量は接続の設定方法や 2 つのマシン間の距離によって変化します。しかし、同じ挙動が発生します。
参考までに、この種の挙動は Babel プラグインなどでも見られますが、Babel プラグインははるかに多くの「同時」書き込みを処理できるようです。「チャット」は実際には隠しトピックですが、その違いは表示方法や「更新」/「プル」の仕組みにあります。この挙動の違いから、私はこれがアプリケーション上の相関関係であり、フロントエンド側の問題がアプリを「クラッシュ」させていると結論づけました（フロントエンドは私の専門外ですが、バックエンドは専門です）。これは、投稿時の操作や、1 分間に数十件のメッセージが投稿されるトピックに待機して「自動更新」を待つ人々によるものです。
これに、人間の要因も加わります。サイトが「もたつく」またはトピックが「期待通りに更新されない」と感じると、人々は F5 キーを連打してリロードし、さらに負荷がかかります。しかし、その点について人々を「教育」するのは大変でしょう 