Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

TLをPush型にする #9325

Closed
syuilo opened this issue Dec 14, 2022 · 64 comments · Fixed by #11946
Closed

TLをPush型にする #9325

syuilo opened this issue Dec 14, 2022 · 64 comments · Fixed by #11946
Assignees
@syuilo
Labels
✨Feature This adds/improves/enhances a feature 🔥high priority 🐢Performance Efficiency related issue/PR

Comments

@syuilo
Copy link
Member

syuilo commented Dec 14, 2022

Summary

DBへのリクエストを1でも減らしたい
@syuilo syuilo added the ✨Feature This adds/improves/enhances a feature label Dec 14, 2022
@syuilo
Copy link
Member Author

syuilo commented Dec 31, 2022 •
edited
Loading

Redisはなかなかハードル高いからまずはnodeにキャッシュする？
ただ複数サーバーで運営しているインスタンスだと効果が少なくなる

@syuilo syuilo mentioned this issue Jan 26, 2023
Closed
@tamaina
Copy link
Contributor

tamaina commented Jan 26, 2023

まずはnodeにキャッシュする？

再起動したらすぐにパーになる

@syuilo
Copy link
Member Author

syuilo commented Jan 26, 2023

RedisにTLをキャッシュ(というより構築)するデメリットとしては、TLを取得する際の負荷は劇的に減るけど代わりに投稿する際の負荷が今と比べてかなり高くなる

TwitterもMastodonもそういうTLの実装してるらしい(Push型というらしい)からそのデメリットよりメリットの方が上回るんだろうけど

@tamaina
Copy link
Contributor

tamaina commented Jan 26, 2023

アンテナもPush型…だがちょっと負荷高いか

@syuilo
Copy link
Member Author

syuilo commented Jan 26, 2023

あと単にデータベースにクエリ投げるだけじゃなくなるから実装も結構複雑になる

@syuilo
Copy link
Member Author

syuilo commented Jan 26, 2023

負荷的にはユーザー全員がタイムラインというアンテナを持つようなものだと思っている

@syuilo
Copy link
Member Author

syuilo commented Jan 26, 2023

TwitterやMastodonと違って、Misskeyはそれぞれのノートがリアクション情報を持っているからRedisにあるそれらも適宜更新する必要があるからちょっと他のソフトウェアとは事情が違うかも

@ikuradon
Copy link
Contributor

FYI: Mastodonでの実装 https://github.com/mastodon/mastodon/blob/fdd1facba16db75e425c02807323eb2666688652/app/lib/feed_manager.rb

@syuilo
Copy link
Member Author

syuilo commented Jan 27, 2023

TwitterやMastodonと違って、Misskeyはそれぞれのノートがリアクション情報を持っているからRedisにあるそれらも適宜更新する必要があるからちょっと他のソフトウェアとは事情が違うかも

IDだけ置いとけばいいか

@tamaina
Copy link
Contributor

tamaina commented Jan 28, 2023

なんならidでソートも可能

@syuilo
Copy link
Member Author

syuilo commented Feb 1, 2023

負荷的にはユーザー全員がタイムラインというアンテナを持つようなものだと思っている

データベースにレコードを挿入するのとRedisに値を追加するのだったら後者の方が圧倒的に負荷は低いだろうからそこまで重くはないと思われる

ただローカルのフォロワーが100人いたら100回Redisにリクエスト投げなきゃいけないのかが気になる
1回のリクエストにまとめられるかな

@tamaina
Copy link
Contributor

tamaina commented Feb 5, 2023 •
edited
Loading

別の案

  1. ユーザーごとの自身のノート一覧もRedisにためておく
  2. フォローしている各ユーザーのノート一覧を結合してソートしてタイムラインとする
    Push型のTLにはしない
  3. フォロー数が多いと結合ソートが大変かもしれないので、Push型TLを採用する？

（リストでも同様のことを行えそう）

@syuilo
Copy link
Member Author

syuilo commented Feb 7, 2023

ただローカルのフォロワーが100人いたら100回Redisにリクエスト投げなきゃいけないのかが気になる
1回のリクエストにまとめられるかな

まとめられないっぽい

@syuilo
Copy link
Member Author

syuilo commented Feb 7, 2023

memo
image

@syuilo syuilo added 🐢Performance Efficiency related issue/PR 🔥high priority labels Feb 9, 2023
@syuilo syuilo pinned this issue Feb 9, 2023
@tamaina
Copy link
Contributor

tamaina commented Feb 9, 2023

添付ファイルありのみのTLもキャッシュしたさがある

@tamaina tamaina mentioned this issue Feb 10, 2023
Closed
@tamaina
Copy link
Contributor

tamaina commented Feb 11, 2023

Renoteを積極的に表示しないようにするとなると意外とRenote周りの扱いがきわどいか、というかもういっそのことPostgreSQLにRenote保持しなくてよくねとすら思い始めてきた

@pantasystem
Copy link

pantasystem commented Feb 11, 2023 •
edited
Loading

RenoteをPostgresql上に保持しなかった場合通知周りの構造はどうなる感じでしょうか？
仮にPostgresql上に保持させないようにする場合
通知にRenoteのNoteを参照させるのではなく、Renote先のNoteを参照させるようになる感じでしょうか？

@acid-chicken
Copy link
Member

MongoDB をキャッシュ用に使うのってどうだろう

@syuilo
Copy link
Member Author

syuilo commented Feb 18, 2023

二種類DB扱うのアレだからPostgreSQLをキャッシュには使えないかな

@acid-chicken
Copy link
Member

ポスグレへのアクセスを減らしたいのならポスグレでキャッシュ作るのが目的を満たしてるのかよくわからない

@syuilo
Copy link
Member Author

syuilo commented Feb 18, 2023

別のポスグレにするとか

@acid-chicken
Copy link
Member

確かに理論上可能だけどキャッシュみたいな捨てる前提のデータベースにマイグレーションとか too much すぎないかとか逆に運用の観点から二つ存在するのがややこしくならないかとかは気になる

@tamaina
Copy link
Contributor

tamaina commented Feb 18, 2023

キャッシュとはいうものの、捨てる前提でRedisにタイムラインを蓄積していたらそれはそれで厄介な実装になりそう

@syuilo
Copy link
Member Author

syuilo commented Feb 18, 2023

キャッシュというか「構築」の方が近いかも

@syuilo
Copy link
Member Author

syuilo commented Apr 5, 2023

アンテナとかチャンネル投稿は(IDだけ)Redisに置くようになった

@syuilo
Copy link
Member Author

syuilo commented Apr 5, 2023

この流れで本丸のHTLもやっていきたい

@syuilo syuilo self-assigned this Apr 5, 2023
@syuilo
Copy link
Member Author

syuilo commented Apr 8, 2023

難しい

@syuilo
Copy link
Member Author

syuilo commented Apr 8, 2023

1万のローカルフォロワーがいたら投稿するごとに1万リクエストをRedisに送信しなきゃいけないのはしんどそう
フォロワーのうちアクティブなユーザーだけに限るとしても、アクティブだけに絞る処理自体が若干重そうだし処理自体もキャッシュとの兼ね合いで複雑になってきそう

@syuilo
Copy link
Member Author

syuilo commented Apr 8, 2023

1リクエストRedisに送る処理が1msだったとしても1ms*10000=10s間はNodeのプロセスが止まりそう

@syuilo
Copy link
Member Author

syuilo commented Apr 8, 2023

よく考えたらアクティブなユーザーだけに限ったとしてもインスタンス規模によっては普通に1万以上はフォロワーがいるわね

@rinsuki
Copy link
Contributor

rinsuki commented Apr 8, 2023

  • 別に送って応答待つところはawaitなので他のことができる
  • Redis は bulk insert できたはず

@syuilo
Copy link
Member Author

syuilo commented Apr 8, 2023

別に送って応答待つところはawaitなので他のことができる

待たなくても「送る」という処理自体が多少なりとも同期的に時間かからない？

Redis は bulk insert できたはず

おー

@syuilo
Copy link
Member Author

syuilo commented Apr 8, 2023

redis xadd bulk で調べても情報がない

@rinsuki
Copy link
Contributor

rinsuki commented Apr 8, 2023

bulk insert というかコマンドまとめて送るくんか https://github.com/luin/ioredis#pipelining

@rinsuki
Copy link
Contributor

rinsuki commented Apr 8, 2023

まあそんな遅さを気にするんだったら適当にキューに積んでやらせるとかでいいかもしれん

@syuilo
Copy link
Member Author

syuilo commented Apr 8, 2023

あとこれをやって本当にパフォーマンス向上するのかが気になってる
投稿全体をRedisに載せられれば良いんだけど、リアクション情報が動的でそれは難しいからIDだけ載せる感じになるし

@acid-chicken
Copy link
Member

こればっかりは実際にやったときの実測データが全てを語るので
考えすぎてもあまりみたいなのはあるかも

@yuriha-chan
Copy link
Contributor

yuriha-chan commented Apr 25, 2023 •
edited
Loading

フォロワーの取得から各TLにIDを入れるまでLuaスクリプトでやる想定でどれくらい速度がでそうか実験
https://colab.research.google.com/drive/1incmhgdmhDuwefB8xCJLLVJq_EG-tQTg?usp=sharing
呼び出し側はほぼ負担なしで、redis側もフォロワー10kがたまに投稿するくらいなら一台でも捌けそうな印象（0.1秒とかくらい）

@syuilo syuilo changed the title TLをデータベース上に直接構築 TLをPush型にする Apr 26, 2023
@yuriha-chan yuriha-chan mentioned this issue May 8, 2023
Open
@syuilo syuilo unpinned this issue May 19, 2023
@tamaina
Copy link
Contributor

tamaina commented Jul 2, 2023

LTLだけはpush型にしてもよかったのでは…

@tamaina
Copy link
Contributor

tamaina commented Jul 2, 2023

というか混雑対策としてSTLとLTLをストリーミングのみにする（local-timeline/hybrid-timelineが空配列を返す）モードがあるとよさそう？

@tamaina
Copy link
Contributor

tamaina commented Jul 2, 2023

というよりはストリーミングを先に繋いで後からapi叩いた結果を繋げばいいか

@yuriha-chan yuriha-chan mentioned this issue Jul 3, 2023
Open
@tesaguri tesaguri mentioned this issue Aug 25, 2023
Open
@syuilo
Copy link
Member Author

syuilo commented Oct 1, 2023

やるか

@syuilo
Copy link
Member Author

syuilo commented Oct 1, 2023 •
edited
Loading

ミュートの考慮が面倒そう

@syuilo
Copy link
Member Author

syuilo commented Oct 1, 2023

難しい

@syuilo
Copy link
Member Author

syuilo commented Oct 1, 2023

ミュートはTL取得時に処理する

@syuilo
Copy link
Member Author

syuilo commented Oct 1, 2023

ファイルが添付されたノートのみオプションが指定されている場合の対応も難しい

@syuilo syuilo mentioned this issue Oct 1, 2023
Merged
25 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@syuilo syuilo

Labels
✨Feature This adds/improves/enhances a feature 🔥high priority 🐢Performance Efficiency related issue/PR
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: improve tl performance misskey-dev/misskey
7 participants
@ikuradon @syuilo @rinsuki @tamaina @acid-chicken @pantasystem @yuriha-chan