私の提案は、シームレスに統合することを目的として、チャット製品を評価することです。
Ephemera は Discourse に属しません。
私の提案は、シームレスに統合することを目的として、チャット製品を評価することです。
Ephemera は Discourse に属しません。
ここは非常に注意が必要です。一度に一つのチャットトピックに絞り、古いトピックは徹底的に削除してください。サーバーには、存在し続けるメガトピックごとに激しいパフォーマンスの低下が生じ、その影響はページビューが増えるたびに大きくなります。
ただし、実際のチャットツールを統合するのが最も良い方法です。詳細は以下をご覧ください。
これに100%賛成です。時にはコミュニティに価値を加えることもありますが、コード変更を必要とするほどではないと思います。
このパフォーマンスへの影響について、もう少し詳しく説明していただけますか?これは閉鎖済みかつアーカイブされたトピックに関するものですか?トピックを 1 万件の時点で閉鎖するのは問題ありませんが、削除するのは全く別の話になります。
私のコミュニティは Discourse を大変気に入っており、15 年以上にわたりフォーラム形式で運営されてきました。チャットルームは利用しませんし、古いトピックが削除されることに対しては非常に否定的に反応するでしょう。これらのトピックが単に存在するだけで深刻かつ増大するパフォーマンス問題を引き起こすのであれば、それらを静的ページとして出力するか、別のプラットフォームへ移行する必要があるでしょう。
私のコミュニティが Discourse の想定する使い方に合致していないことは理解しています。しかし、私が責任を負っているのはこのコミュニティであり、強制的に変更させることができない点もあります。実際、Discourse を導入して以降、コミュニティはこれまで以上に強固になっています。皆が現在の設定に満足している中で、別のプラットフォームへ移行しなければならないのは避けたいと考えています。
メガトピックは、閉鎖済みまたはアーカイブ済みであっても、基本的に非表示にする必要があります。ユーザーがメガトピックにアクセスすればするほど、サーバーのパフォーマンスは低下します。理想的には、メガトピックは削除して、同時にアクティブなものを 1 つだけにするのが良いでしょう。これが私の推奨する対応です。メガトピックが増えれば増えるほど、リスクも高まります。
もし問題に対して多額の資金を投入できるなら、サーバーを大幅に過剰供給してより多くのメガトピックをサポートすることも可能ですが、それでもすべてのトピックの平均的なパフォーマンスには影響が出ます。
トピックが閉じられていても、データ、トラフィック、負荷を生成し続けます。
すべてのユーザーの読了位置が各トピックに対して記録されていることを忘れないでください。各投稿に「いいね」をつけることもでき、メガトピックが閉じられた後もインタラクションは可能です。さらに、検索結果にノイズを発生させる量も考慮する必要があります。
それでも、なぜ特にメガトピックが問題を引き起こすのかは説明されていません。なぜ1万件の投稿があるトピック1つが、1,000件の投稿があるトピック10個よりも悪いのでしょうか?後者の場合、潜在的に「いいね」をつけたり検索されたりする投稿の総数は同じですが、閲覧位置と検索対象となるトピックの数は10倍になります。あなたの説明だけでは、より多くの小規模なトピックの方が問題になると結論づけられます。つまり、それ以上の要因があるはずです。
一度にトピックを1つしか読み込んでいないからです。軽いものを10個()なら、問題なく一度に1つずつ取得できますが、1万個を一度に取得するのははるかに困難です。
ただ、具体的な仕組みが気になりますね。スクロールする前にデフォルトで読み込まれる投稿数には上限があるようですから、単純に「表示されている投稿数」の問題ではないのは明らかです。これはタイムラインの仕組みによるものなのでしょうか?それともトピックの要約によるものなのでしょうか?あるいは、トピック内の投稿総数に基づいた、線形またはそれ以上の計算量を持つアルゴリズム全般に起因するのでしょうか?
「メガトピック」については、その定義にもよりますが、特に気にしていません。私がよく利用するコミュニティのセクションでは、投稿数が最も多いトピックは約3,600件ですが、10位はわずか600件、25位に至っては300件程度です。現時点では、どちらかといえば技術的な観点からの興味の方が強いですね。
ご質問への回答を試みるために、私が書いたデータエクスプローラーのクエリをご紹介します。異なるトピックやオフセットで試してみてください。
-- [params]
-- int :topic_id = 107216
-- int :offset = 10000
SELECT "posts"."id" FROM "posts"
WHERE ("posts"."deleted_at" IS NULL)
AND "posts"."topic_id" = :topic_id
AND "posts"."post_type" IN (1,2,3) ORDER BY "posts"."sort_order" ASC LIMIT 20
OFFSET :offset
通常のサイズのトピックと、非常に巨大なトピックの例です。
Example time: 3.4ms
-> Index Scan using index_posts_on_topic_id_and_sort_order on posts (cost=0.43..1925.22 rows=477 width=8)
example time: 353.9ms, 739.6 ms (time varies depending on database caching)
-> Index Scan using index_posts_on_topic_id_and_sort_order on posts (cost=0.43..605155.88 rows=161255 width=8)
750ms を超える時間を見たこともあります。
以下は中央値と 99 パーセンタイルの時間です。中央値の時間は驚くほど良好ですが、中央値の性質上、60 パーセンタイルで中央値の場合よりもはるかに悪いかどうかはわかりません。
別のサーバーの例です(このサーバーはカテゴリ数が非常に多く、これもパフォーマンスに影響を与えているため、メガトピックがない限り単純な比較はできませんが)、中央値のパフォーマンスは半分になり、最悪の場合も大幅に改善されていることがわかります。
私も同じです。単なる好奇心からですが。
この説明によると、メガトピック内を移動するとパフォーマンスが悪化する可能性があることは理解しています。
しかし、1 つまたは複数のメガトピックが、例えばトピック一覧のような、フォーラム内の他のページでのナビゲーションにどのように影響を与えるのか、理解できません。![]()
サーバーに大量の負荷をかけることでです。メгатピックの読み込み1回ごとに、パフォーマンスへのペナルティが100倍になります!あなたのすぐ上の投稿をご覧ください。
こんにちは、
現在 Discourse にインポートしているフォーラムには、メгатピックが多数あります:
メгатピックは Discourse と相性が良くないため、実際にはどう対処すべきでしょうか(将来的にはコミュニティ向けにチャット、おそらく Discord の導入を検討していますが、現在のトピックについてはどうすればよいか知りたいです)?
削除する?
分割して閉じる?
分割する場合、トピックあたりのメッセージ数は何件が適切でしょうか?デフォルトの 10000 件で十分でしょうか、それとも減らすことをお勧めしますか?
1 万チャンクに分割すれば十分でしょう。
さらに、それらのほとんどは問題なさそうです。本当に深刻な問題は1万から始まります。スクリーンショットに写っているものの大部分は1万未満です。
メガトピックのパフォーマンスへの影響に関する最新情報はありますか?COVIDパンデミックのフォローアップトピックが1万件の投稿に近づいており、最近の遅延の可能性を分析しています。
サーバーの統計が「あるべき」姿がどうなのかはわかりませんが、多数のメガトピックを持つコミュニティの現状を共有できます。現在、1 万投稿以上のクローズトピックが 15 件、2 千投稿以上のオープントピックが 50 件以上あります。フォーラムの活動は、常に非常にアクティブなトピックの少数に集中しています。
現在は、4 個の仮想 CPU、8 GB のメモリ、160 GB のディスクを備えた DigitalOcean サーバーを運用しており、月額 40 ドルです。数ヶ月に一度、ごく短時間ですが、ユーザーが「極度の負荷」メッセージを表示することがあります。これは、ライブイベントが発生し、多くのユーザーが同時に投稿する際(例えば、1〜2 時間にわたって単一のトピックで毎分複数の投稿が平均的に発生する場合)にのみ起こります。
それ以外の時間は、問題なくスムーズに動作しています。現在、他のものをアップグレードする必要があるよりもはるかに前に、ディスク容量の増加が必要になる見込みです。
それは良い数字ですね。2千件の投稿は問題ありません。1万件以上のトピックが数十件あるのもおそらく大丈夫でしょう(特にクローズドな場合)。危険領域は、アクティブなメガトピックが「多数」ある場合です。「多数」の定義は、数十件を超えるとします。
メタではメガトピックは一般的に問題ではありませんが、多くのコミュニティにとって議論を整理する自然な方法のようです。つまり、議論に自然な区切りがないということです。
Inderesはフィンランドの企業で、株式市場向けの財務分析を提供しています。同社は最近Discourseコミュニティを立ち上げ、地域やニッチを考慮すると、大成功を収めています。
議論は主に銘柄や投資商品ごとに整理されています。例えば、$AAPLや$TSLAなどです。現在、わずか2年ほどで、これらのトピックの多くが1万件の返信に近づいています。これはDiscourse(ゼロから構築された活気あるコミュニティ)にとって素晴らしい実証例ですが、同時にメガトピックの問題も浮き彫りにしています。
何より、年ごとに分割できます。これは最初の投稿で説明されています。メガトピックはしばらく機能しますが、数が多すぎると、最終的にサイトがダウンしてしまいます。
(また、同じ「トピック」内に数万件の投稿があると検索が地獄になります。基本的にチャットルームを作っているようなものです。)