taichan

タイムラインが穏やかなサーバーでDBへのフォールバック頻度が増えることはあまり大きな問題ではない気がする、それだけアクティブなユーザーも少なくなることが予想されるので（また、DBフォールバックは無効にもできる） むしろLTLが緩やかなサーバーではより取得漏れが起きやすく深刻 フォローが0人のときもSTLで同様に毎回フォールバックが起きる問題が発生してしまう フォールバック回数抑えつつ取得漏れをなくすにはよりもっと根本的なところを変える必要がある…？

~なんかいけそうな気がしてきたので改良するか~ なんでいけそうな気がしてきたか忘れた

> タイムラインの更新が緩やかなサーバー、ユーザー個人のタイムラインの場合FTTを利用できずDBにフォールバックしてしまう割合が高くなりそうという懸念点がありそうです ユーザーTLではDBにフォールバックさせないようにしました（これは取得漏れをさせずDBフォールバックをしない実装するのが難しいため） そのうえでタイムラインが緩やかなサーバーに関する懸念に関してはそもそもDBへの参照回数もユーザー数が少なければ落ちるのであまり問題ないと考えています

FanoutTimelineNameごとにdbFallbackの手段があれば単純にその区間の行数のcountをしてくればいいのでもう少し楽になりそうではある

Note: >現在のmasterにこれを取り込むと https://github.com/misskey-dev/misskey/pull/13978 でSTLに追加したlocalTimelineWithReplyTo:${userId}によりSTLの一部の(db fallbackすると落ちるタイプの)テストが落ちることが確認されています (https://github.com/niri-la/misskey.niri.la/pull/217 等が実際に落ちてる事例になります) https://github.com/niri-la/misskey.niri.la/pull/217/commits/92a55ade4300aecc2a4d49e8f82f75893b0534c6 のようにテスト環境で挙動を回避すれば問題なさそうなのは確認したし正しそう > これの対策にもなり、またredistimelineがからになってしまってすべてのノートをdbから取得してしまう問題の対策として、各種TL要素のうちuserTimeline${string}:${userId}や${timeline}WithReplyTo:${userId}のようにユーザに関わるものについて、ユーザがアカウントに登録した際に一つだけダミーのデータを追加するというのはどうでしょうか。 これは確かにこれから作成するユーザに関してはユーザー作成時にやれば解決はできるけど、既存ユーザーのうち対象となるノートが一個もない人では引き続き同じことが起きる上にそれを既存ユーザーにまで適用しようと思うとデータを全部作ってあげるのが大変そうな気が…？（純粋に参照されたときになければ作るでいいかもしれないけど）

Redis自体の内容が飛んだ場合や大規模サーバーで休眠ユーザーが多い場合とかはある程度考えた方がいいかも（実際割合どれぐらいいるのかわからないので有識者が意見してくれる方がありがたい）

すこし分かりにくいので図解（横軸はノートの作成時刻） 

広告の場合は同サイトでも別タブで開いて欲しくない？って思ったけど同じタブのがいいのかしら

related: https://github.com/misskey-dev/misskey/issues/13411

ミュートじゃなくてブロックなので一応別issue扱い