スケーリングディスコースチャット高チャネルボリューム向け:制限、REST API&ベストプラクティス?

皆さん、こんにちは。

私はDiscourse Chatの大規模統合に興味があり、コミュニティからの洞察を求めています。私は約1万ページのウェブサイトを運営しており、各ページは別々のコミュニティ(または対象)を表しています。これは、ページごとに専用のチャットチャネルを作成することを検討している理由です。

いくつかの質問があります:

  1. チャネルの制限:
  • Discourseで非常に多数のチャットチャネルを作成および管理する際の既知の制限は何ですか?
  • ページごとに専用チャネル(10,000チャネル)が実用的でない場合、これらのページをより大きなコミュニティにグループ化またはカテゴリー化するための推奨アプローチは何ですか?
  • ページごとに専用チャネル(10,000チャネル)が実用的でない場合、これらのページをより大きなコミュニティにグループ化またはカテゴリー化するための推奨アプローチは何ですか?
  1. REST APIの利用可能性:
  • チャネルやメッセージを管理するための公式のREST APIや他のプログラムによるインターフェースはありますか?
  1. ユーザーの制限:
  • アクティブユーザーの数や、チャネルに参加できる全体のユーザー数に制限はありますか?
  • 単一のチャネル内で多くのアクティブユーザーを扱う際の同時実行性やパフォーマンスの問題はありますか?
  1. パフォーマンスとリソースの懸念:
  • 多数のチャネル(それぞれに高いメッセージ量がある可能性がある)を持つことがサーバーのリソースに負荷をかけたり、パフォーマンスに影響を与えたりしますか?
  • 高トラフィックのチャットアクティビティを処理する際に役立つ設定やベストプラクティス(例:保持ポリシー、データベースのチューニング)はありますか?
  1. ベストプラクティスと代替策:
  • 同様の設定(例:ページごとのチャネルやページをより広範なコミュニティにグループ化)を実装した人はいますか?そして、その際にどのような課題に直面しましたか?
  • このようなシナリオでチャット機能を整理し、スケールさせるための戦略を何か提案しますか?

スケーラビリティに関するインサイト、ベンチマーク、設定のヒントなどが役立ちます。チャネルの拡張性や、利用可能なAPIを通じてのチャットの管理と統合に関する提案を歓迎します。

ご協力とフィードバックに感謝します!