ljpp
(ljpp)
47
ありがとうございます。デバッグや試行錯誤に費やすはずだった多くの時間を節約してくださったようです。
この動作の違いから、私はこれがフロントエンド側の問題によるアプリケーションの「クラッシュ」（フロントエンドは私の専門分野ではなく、バックエンドが専門ですが）であり、投稿やトピックへの滞在による「自己更新」を待つ操作（1 分間に数十件のメッセージが投稿される状況）に起因するアプリケーションの相関関係であると結論づけました。
この長大な文を要約すると：「リアルタイムでの高速な議論が詰まる現象」は フロントエンドの問題 というご結論でしょうか？
分析は進みませんでしたが、CPU 負荷は最大に遠く及ばず、約 25% 程度であることだけは確認できました。過去数年で CPU が 100% に達したことは何度もありましたが、先週の土曜日の最新事象ではそうではありませんでした。同時接続ユーザー数は約 150 名でした。
私がバックエンドを疑った理由は、これらのゲームチャットを長年運営しており、以前このような「詰まり」を目にしたことがないという事実です。年々データベースは成長し、現在は 80 万件以上の投稿があります。
この現象を初めて目撃されたのはいつですか？最新のメジャーアップデートによる回帰（バグの再発）ではないでしょうか？当サイトとパフォーマンスは春までは問題なく、夏の間はそれほどユーザーが増加していません。
Babel は驚くほど非効率なプラグインです。したがって、Babel を使用している場合、特に多数のユーザーが同時にアクティブな負荷下では、大変な思いをすることになります。
sam
(Sam Saffron)
49
現在、バックログに「1,000 人が同じトピックを閲覧している状況で、1 人が投稿した際の性能を改善する」という TODO が追加されています。
現在の設計では、1,000 人全員に「こんにちは、このトピックに新しい投稿があります」という通知を配信し、その後、その 1,000 人が（ほぼ同時に）サーバーに対して「ねえ、あなたが要求している新しいトピックって何？」と問いかけます。
クライアントがサーバーを過負荷にしないよう、この処理をよりクリーンに最小限のレート制限をかける方法を検討しますが、この稀なケースに対しては他にも多くの最適化が可能です。
ljpp
(ljpp)
50
この件が把握されているという知らせ、大変嬉しく思います。昨春以降、この問題が悪化しているかどうかご確認いただけますでしょうか。
地元のホッケーリーグでは、10月1日から試合を開始しようとしています。そのため、当サイトは週に一度、リアルな（シミュレーションではない）環境でトラフィックの急増が発生する可能性があります。もしその挙動を研究する必要やご関心があるようでしたら、ぜひご活用ください。
ご興味があればDMまでご連絡ください。喜んでサポートいたします。
UXの観点からは、システムが負荷に耐えられなくなった際でも、エンドユーザーがディスカッションが活発に行われていることを何らかの方法で把握できるようにする必要があります。これにより、不要なブラウザのリフレッシュを防ぐことができるかもしれません。
sam
(Sam Saffron)
51
いいえ、残念ながら確認できません。これは以前からそうなっています。
ljpp
(ljpp)
52
最初の試合がちょうど終了し、3 月にはなかった明らかな問題が発生しています。原因は未だ不明です。
ゲームチャットがフロントエンドで詰まりますが、サーバー負荷は 100% を大幅に下回るはずです。
Ole 氏を含む複数のユーザーが、詰まり中に 429 状態コードのサーバーレスポンスを複数確認しましたが、試合中にこのような調査を行ったことがないため、これが「正常」かどうかは判断できません。
@iceman さん、あなたのサイトでも同様の現象が見られましたか？
Benjamin_D
(Benjamin Decotte)
53
全く関係のない「500」エラーを調査中に、そうしたレスポンスを1回見たことがあります:sweat_smile:
サーバーは全く繁忙していなかったのですが、フロントのnginx設定（http2）をいじっていました。
「ゲームチャット」とは、「同じトピックに多数のユーザーが同時にアクティブであること」を指しますか？
rizka
(rizka)
55
確かに、数時間の間に約 900 件の反応的な返信がありました。@ljpp がより正確なユーザー数を把握していますが、試合中は常に数百人のユーザーがトピックを閲覧していました。
奇妙なことに、これはすべてのユーザーに影響しているわけではありません。例えば、私はどの端末でも問題に遭遇していません。しかし、報告によると、影響は広範囲に及んでいます。
ljpp
(ljpp)
56
特に注意深く見ていない限り、気づきにくいものです。
まず、30〜60秒ほど返信が途切れることがあります。何か「おかしい」というわけではありませんが、ただ静かになります。自分でも投稿することはできます。すると突然、一瞬のうちに数十件のメッセージが流れ、自分が遅れていたことに気づきます。これはiOSのSafariやAndroidのChromeでも確認しています。
当社のリアルタイムゲームチャットは活発ですが、極端なケースではありません。昨日は約3時間で972件のメッセージがありました。
次のゲームチャットは本日14:00（UTC）に開催されます。パンデミックの影響により、ホームゲームであっても同程度の件数になることを予想しています。
@pfaffman さんのこの投稿には同意します。
forum プラットフォームにチャット用途を無理やり押し付けようとしているのではないでしょうか？
代わりに、Mattermost や Discord などのチャットサービスを Discourse サイトの UI に統合し、ゲーム内の議論はそのチャットで行うのはどうでしょうか？
ゲームに関する議論は、プレゲームやポストゲームの議論など、forum トピックとして別の方法で扱うこともできます。利用負荷はそれほど高くなくても、後で多くのユーザーが参照したいような有用な要約情報が含まれているかもしれません。
また、即興のチャットを大量に forum に保存することのメリットも見えません。本当に誰かがそれを再び読むのでしょうか？それは有用なのでしょうか？
まあ、彼はこれを「チャット」と呼んでいますが、ユーザーによると、Discourseのセットアップではトピック内で「約3時間にわたる972件の投稿」を処理できないとのことです。個人的には、これでも処理できるべきだと思います。シンプルなphpBBでも、これより数倍多くの投稿を3時間で処理できますから。
つまり、10秒に1投稿ですか？それだけなら、それほど不合理には聞こえません。しかし、トピックを1000投稿もの長さにし、数百人のユーザーが参加し、さらに投稿の急増が起きるようになれば、確かに課題が見えてきますね！
しかし、ここでの真の犯人やボトルネックは何でしょうか？参加ユーザーの数なのか、10 秒に 1 件の投稿なのか、変更されたコンテンツを（多すぎる）匿名/非匿名ユーザーにレンダリングすることなのか、それとも多数のログインユーザーにサービスを提供するために必要な接続数なのでしょうか？
もし同じ時間枠内で同じ量の投稿を 2 人のユーザーだけがトピックで行った場合、同じ問題が発生するでしょうか？
たとえ 972 人のログインユーザーがそのトピックで 1 件の投稿だけを行ったとしても、Discourse はこれを処理できないのでしょうか？もしできないなら、なぜでしょうか？Discourse は、同時ログインユーザー数が非常に少ないごく小規模なコミュニティに最適な選択なのでしょうか？
私たちがすでに時折 400 人の同時ログインユーザーを持ち、1 日に最大 3000 件の投稿を生み出しているにもかかわらず、これまで問題が発生していないことから、単に疑問に思っています…
merefield
(Robert)
61
サーバーの仕様と稼働中のユニコーンの数を明確に考慮する必要があります。そうでなければ、これらのストレステストの結果はあまり意味を持ちません。
Blenderartists (@bartv) は、64GB のサーバーと約 12 頭のユニコーンを稼働させていると聞いていますが、かなりの化け物ですね 
もちろん、現在は DO で 8 GB メモリ / 4 vCPU を使用しており、特に問題はありません。つまり、この問題の解決策が単にリソース（RAM と CPU）を追加することなら、私にとっては問題ありません。Discourse を再公開してからのピーク時には、ある投稿がバズり、同時接続数が約 2000 人に達しましたが、その際の負荷は 1 をわずかに超える程度で、CPU 使用率は 60〜70% でした。現在、同時接続ユーザー数が約 200〜250 人の平均的な状況では、CPU 使用率は 15〜20% 程度で余裕があります。
bartv
(Bart )
63
その通りです データの共有は喜んで行いますが、Discourse をチャットとして利用しているわけではなく、そのような急激な増加を見ることはありません。
ljpp
(ljpp)
64
その指摘はできるかもしれませんが、私は会話を2つのプラットフォームに分割するというアイデアを本当に嫌っています。リアルタイム性は、実際にはエンドユーザーが評価している Discourse のキラー機能の一つです。私たちのゲーム中の会話は非常に人気があり、コミュニティ文化の重要な一部となっています。
なお、私たちはこの機能を4年間運用しており、これは今直面している新しい問題です。つまり、「無理やり」押し付けることなく、数百のゲームが円滑に進行してきました。
私たちの知識豊富なメンバーの一人は、Discourse のグローバル制限に達している可能性があり、CloudFlare が影響を与えているかもしれないという仮説を立てました。
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE : IP あたりの1分間のリクエスト数（デフォルトは200）
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS : IP あたりの10秒間のリクエスト数（デフォルトは50）
次のゲームは1時間後にあり、CF キャッシュを無効にして試してみます。
なお、一般的には推奨されていませんが、私たちは4年間 CloudFlare を使用しています。その間、Brotli や更新されていないテンプレートなど、1〜2件の問題しか発生していませんでした。
ljpp
(ljpp)
65
いいえ、CFが根本原因ではありません。キャッシュを無効にしても問題が再現しました。429エラーが報告されました。
何かアイデアはありませんか？
はい、そのご懸念は理解できます。貴重な洞察がチャットに埋もれて記録として失われるのは避けたいですね。これは難しいジレンマです。