@ito_kika 投稿にリアクションした際は、投稿主のサーバにリアクションを一つだけ送ります。

リアクションを受け取ったサーバが、投稿主のフォロワー全員にそれを転送しています。

またこれはMisskeyとFedibirdの現在の挙動ですので、他のリアクション対応サーバで同じ挙動になる保証はありません。 #fedibird [参照]

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

でかいゆれ！

タイムラインは遅延しやすいので、NERVアプリなど地震防災系アプリを参照ください

例によってfedibird.comは遅延中です。（もう少しサーバに余裕が欲しいネー）

サーバ内のタイムライン表示が遅延していますが、投稿はあまり遅延なく外部に配送されるので、気にせず投稿して大丈夫です。

個々人のホームやリストより、ハッシュタグタイムラインはいくらかマシなので、そちらもご活用ください。
#fedibird #fedibird_info

よし、ウチの遅延は解消かな。 #fedibird

なしきおるやん

まぁ、サーバもう1台ぐらい増やせばだいぶマシになるとは思うんよね。

コードを見直した方がいいという話もあるけども！

@makihara えとね、ざっくり3ステップあるわけ。

最初にWebサーバが外部からの投稿データを受け取って、

1. ActivityPub::ProcessingWorker
2. DistributionWorker
3. FeedInsertWorker

という順序でワーカーが起動。

(1)は投稿データを解析して、投稿データとしてデータベースに記録＋通知＋(2)の起動

(2)はそれを全員共通のタイムラインに配送＋(3)の起動

(3)はひとりひとりのタイムラインに配送

で、処理が詰まっている（順番待ちになっている）と、ひとりひとりのタイムラインに表示されるまでに3回待たないといけないのね。だから2倍も3倍も遅延するっていう。

購読とフォローはどちらも(3)で処理するから同じだよ。

ハッシュタグタイムラインは(2)で処理される。

内部の投稿は(1)の代わりに投稿APIの処理が走って、あと(2)以降は同じ。

@makihara フォローと購読で、購読の方が軽い場合というのは、

1. 購読は（主に）公開投稿だけを処理するので、処理対象が少ない（なので公開投稿しかしない相手なら同等）

2. フォローされている側としては購読者を認識していないので、送り先リストの件数が減る。減るけど、一つのサーバに一つしか送らないので、実はさほどの差ではない

ってぐらいかなあぁ。

@makihara ですです。

なお、購読系機能と専用タイムラインの両方がある場合、

a. ハッシュタグフォロー（購読）
b. ハッシュタグタイムライン

a. ドメイン購読
b. ドメインタイムライン

ってことだけど、これは後者(b)の方が個別配送しないので待ち時間が短いです。

普段は使い勝手で考えればいいけど、詰まってる時は後者の方がサーバ負荷も軽いし使う人も有利。だいたいWebUIからじゃないと見えないけど。

@makihara リレーでしか受け取ってないアカウント（所属鯖から誰もフォローしてない）の場合、フォローされる側からすると軽くなるかな。

ま、負荷のことは考慮に入れなくていいと思います。

@makihara あとこれは本質なんですが、

ホームやリストというのは、800件とか1,200件、投稿を蓄えておく入れ物です。溢れると消える。

ハッシュタグ、ドメイン、ローカル、連合などは、全員共通なので配送が1回っていうこともあるけど、一時的な入れ物じゃなくて、配送されなくても最初から最後まで全部入っているということが決定的に違います。

@pumel 一番見落としがちなのはピン留め。でもそうじゃなかったらフォロワーいなかった時期のものは伝わらないね、普通は。

@pumel あ、気付きましたね……そうです、ピン留めすると連合先に投稿を再配送できる仕組みです。

リモートからみると、初めて認識したアカウントは投稿がゼロなので不審がられたり興味を持ってもらえないので、ピン留めはかなり重要だったりします。