feat: queueing bulk follow/unfollow and block/unblock #10544
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #10544 +/- ##
===========================================
- Coverage 75.11% 73.89% -1.23%
===========================================
Files 886 727 -159
Lines 87116 67562 -19554
Branches 5910 5594 -316
===========================================
- Hits 65439 49925 -15514
+ Misses 21677 17637 -4040
... and 169 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
nmkj-io
changed the title
|
Misskey ↔ Mastodon の通信は一旦外のVPSを経由させるようにしたので、deliver・inboxキューの遅延も含まれていると思われます。 |
nmkj-io
changed the title
|
良さそうです👍 |
|
forで大量にQueueを追加しているけど、dbQueue.addBulkを使っていい感じにできないかしら |
|
（できそうなのでできたらコードを変えて欲しい |
|
リファクタリングの余地はあるかと思いますが、フォローとブロックのインポートで 例えば ImportFollowingProcessorService.ts の 追加の変更として、インポート時は |
|
実験では 4000 アカウントを一気にフォローインポートしましたが、実際は CSV ファイルのサイズ制限で引っかかるので |
|
指示が間違ってた(relationshipQueue.addBulkを使うと言った方が適切だった |
一応
とあるように、 どちらがよいでしょう？ |
|
ようは |
ので、 一行一行findOneByするからキューにしてるんだわこれ |
|
さっき10人ごとにって言ったけどあんまり良くないな |
|
userオブジェクトをBullに無限に突っ込む操作だけはやめた方が良さそう （processDbごとにfindしてもキャッシュが効くだろうしなんとかなる |
|
processDb には ThinUser 渡して、キャッシュが効くのを期待して中で findOne させるというのはどうでしょう？ createFollowJob も同様だとすると RelationshipProcessorService.ts の processFollow 内でも findOne するので二回呼びますが、キャッシュが効いて影響なしならいけるかと。 ただしSQL発行量は指数的に増えるんじゃないかと思います。 |
|
というかprocessDbでフォローインポートしたユーザーを読み出す必要はないはず |
|
ImportFollowingProcessorServiceでインポート操作を行ったユーザーをfindOneByする意味自体が薄い |
でしたら、 processDb はそのままインポートしたユーザーの ThinUser を createFollowJob に渡して、findOne は UserFollowingService の follow まで遅らせることができますね。 |
そう |
|
意味が薄いとは言ったけど、processの最初でユーザーの存在確認をするのはまあいたずら防止程度の意味はありそうなのでそのままでいいかと とにかくBullにUserを突っ込むのは極力やめる方針で |
|
（というかidからfindOneする処理ぐらいは流石に回数を重ねても問題ない） |
|
では RealtionshipProcessorService がジョブの最小単位なのでそこに ThinUser を渡して中で findOne するようにしますね。（processFollowでは不要なのでそのまま受け渡し） |
|
Bull に渡すユーザーを全てThinUserに置き換えました。RelationshipProcessorService で findOneByOrFail を呼ぶようにしました。 |
|
すみません、suspend-userでfollowerとfolloweeが逆になってたので修正（83, 84行目） |
これはめちゃくちゃいいアイデアだと思います いくつかリファクタリングなどを追加したので、この状態でもう一度テストしていただけるとありがたいです |
|
リファクタリングありがとうございます。100アカウントx4000フォローの400,000ジョブでテストしたところ、フォロー・ブロックインポート共に正常に動作しました。4000x4000の16,000,000ジョブはRAM 8GBではRedisがメモリ不足になりましたが、ThinUserに変える前よりは多くのジョブがさばけました。（メモリ不足になっても落ちずにそのまま止まったジョブから再開しました） adminのsuspend-userとremove-all-followingのAPIについてもUnfollowのジョブが多くなる可能性があるのでsilent=trueにしておきました。 |
|
@syuilo We're ready for merge |
|
👍🏻👍🏻👍🏻 |
* Refactor sw (misskey-dev#10579) * refactor(sw): remove dead code * refactor(sw): remove dead code * refactor(sw): remove dead code * refactor(sw): remove dead code * refactor(sw): remove dead code * refactor(sw): remove dead code * refactor(sw): 冗長な部分を変更 * refactor(sw): 使われていない煩雑な機能を削除 * refactor(sw): remove dead code * refactor(sw): URL文字列の作成に`URL`を使うように * refactor(sw): 型アサーションの削除とそれに伴い露呈したエラーへの対処 * refactor(sw): `append` -> `set` in `URLSearchParams` * refactor(sw): `any`の削除とそれに伴い露呈したエラーへの対処 * refactor(sw): 型アサーションの削除とそれに伴い露呈したエラーへの対処 対処と言っても`throw`するだけ。いままでもこの状況ではエラーが投げられていたはずなので、この対処により新たな問題が起きることはないはず。 * refactor(sw): i18n loading * refactor(sw): 型推論がうまくできる書き方に変更 `codes`が`(string | undefined)[]`から`string[]`になった * refactor(sw): クエリ文字列の作成に`URLSearchParams`を使うように * refactor(sw): `findClient` * refactor(sw): `openClient`における`any`や`as`の書き換え * refactor(sw): `openPost`における`any`の書き換え * refactor(sw): `let` -> `const` * refactor(sw): `any` -> `unknown` * cleanup(sw): import * cleanup(sw) * cleanup(sw): `?.` * cleanup(sw/.eslintrc.js) * refactor(sw): `@typescript-eslint/explicit-function-return-type` * refactor(sw): `@typescript-eslint/no-unused-vars` * refactor(sw): どうしようもないところに`eslint-disable-next-line`を * refactor(sw): `import/no-default-export` * update operations.ts * throw new Error --------- Co-authored-by: tamaina <tamaina@hotmail.co.jp> * Update CHANGELOG.md (misskey-dev#10591) * feat: queueing bulk follow/unfollow and block/unblock (misskey-dev#10544) * wrap follow/unfollow and block/unblock as job queue * create import job to follow in each iteration * make relationship jobs concurrent * replace to job queue if called repeatedly * use addBulk to import * omit stream when importing * fix job caller * use ThinUser instead of User to reduce redis memory consumption * createImportFollowingToDbJobの呼び出し方を変える, 型補強 * Force ThinUser * オブジェクト操作のみのメソッド名はgenerate...Data * Force ThinUser in generateRelationshipJobData * silent bulk unfollow at admin api endpoint --------- Co-authored-by: tamaina <tamaina@hotmail.co.jp> * perf(backend): ノート作成時のアンテナ追加パフォーマンスを改善 * update CHANGELOG.md * refactor: サウンド関連の設定をpizzaxに移行 (misskey-dev#8105) * enhane: unison-reloadに指定したパスに移動できるように * null * null * feat: ログインするアカウントのIDをクエリ文字列で指定する機能 * null * await? * rename * rename * Update read.ts * merge * get-note-summary * fix * swパッケージに * add missing packages * fix getNoteSummary * add webpack-cli * ✌️ * remove plugins * sw-inject分離したがテストしてない * fix notification.vue * remove a blank line * disconnect intersection observer * disconnect2 * fix notification.vue * remove a blank line * disconnect intersection observer * disconnect2 * fix * ✌️ * clean up config * typesを戻した * backend/src/web/index.ts * notification-badges * add scripts * change create-notification.ts * Update packages/client/src/components/notification.vue Co-authored-by: Acid Chicken (硫酸鶏) <root@acid-chicken.com> * disconnect * oops * Failed to load the script unexpectedly回避 sw.jsとlib.tsを分離してみた * truncate notification * Update packages/client/src/ui/_common_/common.vue Co-authored-by: syuilo <Syuilotan@yahoo.co.jp> * clean up * clean up * refactor * キャッシュ対策 * Truncate push notification message * fix * wip * clean up * migration * migration * comment * move soundConfigStore * ✌️ * clean up * クライアントがあったらストリームに接続しているということなので通知しない判定の位置を修正 * components/drive-file-thumbnail.vue * components/drive-select-dialog.vue * components/drive-window.vue * merge * fix * remove reversi setting * Service Workerのビルドにesbuildを使うようにする * return createEmptyNotification() * fix * fix * i18n.ts * update * ✌️ * remove ts-loader * fix * fix * enhance: Service Workerを常に登録するように * pollEnded * pollEnded * URLをsw.jsに戻す * clean up * clean up * update sounds.vue * update * fix type * ✌️ * ;v; --------- Co-authored-by: Acid Chicken (硫酸鶏) <root@acid-chicken.com> Co-authored-by: syuilo <Syuilotan@yahoo.co.jp> * enhance: カスタム絵文字関連の変更 (misskey-dev#9794) * PackedNoteなどのemojisはプロキシしていないURLを返すように * MFMでx3/x4もしくはscale.x/yが2.5以上に指定されていた場合にはオリジナル品質の絵文字を使用する * update CHANGELOG.md * fix changelog * ?? * wip * fix * merge * Update packages/frontend/src/scripts/media-proxy.ts Co-authored-by: syuilo <Syuilotan@yahoo.co.jp> * merge * calc scale --------- Co-authored-by: syuilo <Syuilotan@yahoo.co.jp> * feat: role timeline Resolve misskey-dev#10581 * feat(server): Misskey Webでユーザーフレンドリーなエラーページを出す (misskey-dev#10590) * (add) user-friendly error page * Update CHANGELOG.md * (add) cache-control header * Add ClientLoggerService * Log params and query * remove error stack on client * fix pug * 文面を調整 * :art] --------- Co-authored-by: tamaina <tamaina@hotmail.co.jp> * test(backend): Add tests for users (misskey-dev#10546) Co-authored-by: tamaina <tamaina@hotmail.co.jp> * fix(backend): カスタム絵文字でリアクションできないことがある問題を修正 * Update CustomEmojiService.ts * fix type * Use unique identifier for each follow request (misskey-dev#10600) Co-authored-by: anemone <anemoneya@icloud.com> * fix type in CustomEmojiService * fix type in CustomEmojiService 2 * fix * Update CHANGELOG.md * fix(server): アンテナとロールTLのuntil/sinceプロパティが動くように (misskey-dev#10605) * fix(server): アンテナとロールTLのuntil/sinceプロパティが動くように * fix * Update CHANGELOG.md * Update about-misskey.vue * 🎨 * fix(backend): チャンネルのピン留めされたノートの順番が正しくない問題を修正 Fix misskey-dev#10541 * New Crowdin updates (misskey-dev#10585) * New translations ja-JP.yml (English) * New translations ja-JP.yml (Chinese Traditional) * New translations ja-JP.yml (German) * New translations ja-JP.yml (Japanese, Kansai) * New translations ja-JP.yml (Chinese Simplified) * New translations ja-JP.yml (Italian) * New translations ja-JP.yml (Italian) * New translations ja-JP.yml (English) * New translations ja-JP.yml (German) * New translations ja-JP.yml (Chinese Traditional) * New translations ja-JP.yml (Japanese, Kansai) * New translations ja-JP.yml (Chinese Simplified) * 13.11.3 * [ci skip] remove outdated comment * [ci skip] improve readability * 一部の Workflow を削除 --------- Co-authored-by: okayurisotto <aytkzm@gmail.com> Co-authored-by: tamaina <tamaina@hotmail.co.jp> Co-authored-by: futchitwo <74236683+futchitwo@users.noreply.github.com> Co-authored-by: Namekuji <11836635+nmkj-io@users.noreply.github.com> Co-authored-by: syuilo <Syuilotan@yahoo.co.jp> Co-authored-by: Acid Chicken (硫酸鶏) <root@acid-chicken.com> Co-authored-by: kakkokari-gtyih <67428053+kakkokari-gtyih@users.noreply.github.com> Co-authored-by: Nanashia <nanashia.128@gmail.com> Co-authored-by: hutchisr <42283663+hutchisr@users.noreply.github.com> Co-authored-by: anemone <anemoneya@icloud.com> Co-authored-by: Ebise Lutica <7106976+EbiseLutica@users.noreply.github.com>
|
リモートユーザーばっかだとsilentあんま意味ない感じがした |
|
あとマシンの性能一杯一杯まで使ってジョブキューをこなそうとするのが厳しい感じがある （各種キューにリミッターが欲しい） |
What
フォロー・フォロー解除とブロック・ブロック解除をジョブキューに切り出す。
Resolves #10527
Why
フォローインポートやアカウント引っ越しで大量のフォロー・フォロー解除が発生した際にサーバーが応答不能にならないようにするため。
Additional info (optional)
フォローインポートやアカウント引っ越しのような限定的な場面ではジョブの順序などは考慮しなくてよいと思われます。また、ブロックはフォローに優先されるためフォローインポートとブロックインポートを両方ジョブにしてもよいと判断しました。
以下はテスト用のAPIを作って試した結果です。（コミットには含めていません）
4000ローカルユーザー（Misskey）＋2500リモートユーザー（Mastodon）でテストした結果：
テスト環境： 4コア8GB KVM Core i7-11700K（Postgres, Redis, Mastodon 4.1.2 を同じKVMマシン内で実行）
4以降のケースで全ジョブの完了に30分以上を要しました。いずれも応答不能にはなっていません。
Checklist