Notices by かき＠ひろしま丼 :sabakan: :verify: (oyster@hiroshimastdn.club), page 18

@X おはようです！

明石に住んでる弟一家が心配だ

@munyumunyu おはじっぷjpさん！

@syumari そっちはギンギン！！

@syumari ごめんそっちはおっきしないの…もう…

@syumari きゃーﾔ━━(*ﾉзﾉ*)━━ﾝ☆

#アイマス日めくりカレンダー

@worstman いてらです先生～

@syumari そんな…おパンツ！！＞＜

@syumari おはですー！

@PekePeke おはぺけ！

@ARTi おはようございます～

@haggy おはようございます！

@medph もるげんもるげん

ちなみに、ストリーミングの処理自体は、redisというオンメモリのデータベースを経由して、node.jsによるストリーミング専用のプロセスが行っています。

このプロセスが止まったり異常が発生した場合は、タイムライン上部に「‥‥‥‥‥‥」というマーカーが出て、新しいストリーミング（リアルタイムのタイムライン更新情報）を受け取れていないことが明示されます。

このマーカーをクリックすると再接続を試みますので、一時的な問題の場合は解決します。サーバ側が落ちているときはダメです。

便宜上、ストリーミングが遅延していると表現してしまいますが、ストリーミングサーバが原因であるのではなく、単に配送しろという指令がredisに届いてないだけだったりします。

『sidekiqのdefaultキューの遅延が原因でストリーミングが遅延している』ということになります。

なお、初回ロード、リロードした場合、データベースから直接タイムラインの情報を取得します。

そのため、ストリーミングを経由せずに内容が構築されます。

LTLは、ユーザーが投稿を行って受理された直後にデータベースに反映されるため、ここでは遅延が発生しません。

連合は、ローカルユーザーは遅延なし、リモートユーザーはWorker1回分の遅延となります。

ホームは、FeedInsertWorkerによって内容が構築されるため、ストリーミングと同様にWorker3回分の遅延となります。

Mastodonのdefaultキューの処理が追いつかないと、ストリーミングで古い投稿が流れてくるようになります。

LTLが2時間遅れている場合、FTLは4時間、HTLは6時間程度の遅れになる傾向があります。

これは、defaultキューで順番に処理されるWorkerを、それぞれ1回、2回、3回通過しなければいけないからです。

連合は、リモートから受け取った投稿などをActivityPub::ProcessingWorkerというWorkerが処理したあとで、DistributionWorkerというWorkerが配送します。

ローカルは、所属サーバのユーザーの投稿があると、ActivityPub::ProcessingWorkerを経由せずに直接データベースに内容を反映した後、DistributionWorkerによってサーバ内の各タイムラインに配送処理が行われます。

ホームは、DistributionWorkerの中からさらにユーザー毎にFeedInsertWorkerが走ります。

連合の中のローカルの投稿は、ローカルと同じ遅延になります。

@kanta_v3 寒いので気をつけてー

@kamisuke おは王

@nok_Pawoo グ民