あけおめ
のえる(@noellabo@fedibird.com)の投稿
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator（開発者の一員）です。また、独自機能を盛り込んだFedibirdを管理・開発しています！
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
@iciro16 朝に6時間という予想はオオハズレで、最低でも10時間ぐらいはいきそうな勢いですな……。
このアカウントは、notestockで公開設定になっていません。
@araigumaG 当時、いつの間にか疎通できなくなったしほっとくべ、という判断を下しているのは覚えているんですが、そのときの記録も記憶も薄れてしまいまして……（ぽんこつ）
@offy Fedibirdの現在の登録人数は1,280人です。週のアクティブは600人ぐらいですが、ローカルがないためフォロー関係にある人が何人いるかでしかなく、全体の人数はあまり関係ないかと思います。
Mastodonのdefaultキューの処理が追いつかないと、ストリーミングで古い投稿が流れてくるようになります。
LTLが2時間遅れている場合、FTLは4時間、HTLは6時間程度の遅れになる傾向があります。
これは、defaultキューで順番に処理されるWorkerを、それぞれ1回、2回、3回通過しなければいけないからです。
連合は、リモートから受け取った投稿などをActivityPub::ProcessingWorkerというWorkerが処理したあとで、DistributionWorkerというWorkerが配送します。
ローカルは、所属サーバのユーザーの投稿があると、ActivityPub::ProcessingWorkerを経由せずに直接データベースに内容を反映した後、DistributionWorkerによってサーバ内の各タイムラインに配送処理が行われます。
ホームは、DistributionWorkerの中からさらにユーザー毎にFeedInsertWorkerが走ります。
連合の中のローカルの投稿は、ローカルと同じ遅延になります。
なお、初回ロード、リロードした場合、データベースから直接タイムラインの情報を取得します。
そのため、ストリーミングを経由せずに内容が構築されます。
LTLは、ユーザーが投稿を行って受理された直後にデータベースに反映されるため、ここでは遅延が発生しません。
連合は、ローカルユーザーは遅延なし、リモートユーザーはWorker1回分の遅延となります。
ホームは、FeedInsertWorkerによって内容が構築されるため、ストリーミングと同様にWorker3回分の遅延となります。
ちなみに、ストリーミングの処理自体は、redisというオンメモリのデータベースを経由して、node.jsによるストリーミング専用のプロセスが行っています。
このプロセスが止まったり異常が発生した場合は、タイムライン上部に「‥‥‥‥‥‥」というマーカーが出て、新しいストリーミング（リアルタイムのタイムライン更新情報）を受け取れていないことが明示されます。
このマーカーをクリックすると再接続を試みますので、一時的な問題の場合は解決します。サーバ側が落ちているときはダメです。
便宜上、ストリーミングが遅延していると表現してしまいますが、ストリーミングサーバが原因であるのではなく、単に配送しろという指令がredisに届いてないだけだったりします。
『sidekiqのdefaultキューの遅延が原因でストリーミングが遅延している』ということになります。
最後にひとつ付け加えておきますが、この仕組み上、リロードしまくればローカルの遅延を回避できるということになりますが、サーバに多大な負荷が掛かるため、全体としては症状が悪化します。
遅延している場合は、管理者に不具合状況の連絡を行った上で、回復まで、あまり負荷をかけないように見守ってあげてください。
ポーリングについては、結局これも負荷を高めてしまうため、ここでは説明を割愛します。やめてさしあげろ。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@fujii_yuji アクセス負荷に対してリソースに余力がほとんどなくて、スケールしにくい構成（強いサーバに詰め込み）になってて、管理者がちゃんと監視してない。
@fujii_yuji DSNOから引き継ぎ時に余力ほとんどないことは伝えていて、サーバ移転する前提で話をすすめてたけどキャンセルしてそのまま現行サーバで継続することになってたり、DSNO時代に契約してたメトリクス監視がなくなった後sujitechで対応されてなかったり（初動が遅いのでたぶんまだ）、というのはあります。
ちょっと電源お借りしました。コンセントいっぱいだったので、ついでに綺麗にさし直しておきましたので！
@minipc https://mstdn.beer/@estpls/105546725371413861
（なお、ビア鯖にアカウントありますw）
の投稿
oyster@hiroshimastdn.club
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
サーバ安定させるの、余裕を持たせるのが一番簡単だと思うんですが、金めっちゃかかるし、まぁ無理ですよね……。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Fedibirdから観測するmstdn.jp（フォローされている人だけ）の様子。10分ぐらい死んで、一瞬復活するみたいなのを繰り返してる？
@tangram サイレンスは世間様との接点を制限する措置で、新しい繋がりを作ること、フォロワー以外に自分の存在を伝えることが困難になります。
鍵アカウントじゃないオープンの人をフォローしようとしても、フォローリクエストでワンクッション入ります。
フォローリクエストされた側は、この人、管理者判断で制限かけられてる人だけど、どうする？ って聞かれます。
リプライもある程度制限されるんじゃないかな？ 詳細忘れた。
フェディバは連合がローカルっていう発想のサーバで、連合から色々な情報を拾ってくることができるんですが、そこでも一切自分の情報が表示されなくなります。
