ちなみに、ストリーミングの処理自体は、redisというオンメモリのデータベースを経由して、node.jsによるストリーミング専用のプロセスが行っています。
このプロセスが止まったり異常が発生した場合は、タイムライン上部に「‥‥‥‥‥‥」というマーカーが出て、新しいストリーミング(リアルタイムのタイムライン更新情報)を受け取れていないことが明示されます。
このマーカーをクリックすると再接続を試みますので、一時的な問題の場合は解決します。サーバ側が落ちているときはダメです。
便宜上、ストリーミングが遅延していると表現してしまいますが、ストリーミングサーバが原因であるのではなく、単に配送しろという指令がredisに届いてないだけだったりします。
『sidekiqのdefaultキューの遅延が原因でストリーミングが遅延している』ということになります。
Mastodonのdefaultキューの処理が追いつかないと、ストリーミングで古い投稿が流れてくるようになります。
LTLが2時間遅れている場合、FTLは4時間、HTLは6時間程度の遅れになる傾向があります。
これは、defaultキューで順番に処理されるWorkerを、それぞれ1回、2回、3回通過しなければいけないからです。
連合は、リモートから受け取った投稿などをActivityPub::ProcessingWorkerというWorkerが処理したあとで、DistributionWorkerというWorkerが配送します。
ローカルは、所属サーバのユーザーの投稿があると、ActivityPub::ProcessingWorkerを経由せずに直接データベースに内容を反映した後、DistributionWorkerによってサーバ内の各タイムラインに配送処理が行われます。
ホームは、DistributionWorkerの中からさらにユーザー毎にFeedInsertWorkerが走ります。
連合の中のローカルの投稿は、ローカルと同じ遅延になります。
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。