プロジェクト

全般

プロフィール

バグ #916

完了

定期的にfollowアクティビティが大量に生成される

Osamu Koga さんが7年以上前に追加. 約6年前に更新.

ステータス:
終了
優先度:
通常
担当者:
対象バージョン:
プラグイン名:
followingcontrol
クラッシュする:
いいえ

説明

詳細はよく分からないですが、15分に1回くらい、既に存在するフォロー / 被フォロー関係に対応するfollowアクティビティが大量に生成されます。


ファイル

api_shortcuts.rb.diff (2.47 KB) api_shortcuts.rb.diff Izumi Tsutsui, 2017-12-24 22:52
mikutter-916-test.png (129 KB) mikutter-916-test.png Izumi Tsutsui, 2018-03-03 11:06

関連するチケット

関連している バグ #932: periodイベントが2回発火している終了toshi_a 初音2016-11-14操作
関連している 致命的 #964: フォロー・フォロワータブで何も表示されていない行をクリックすると落ちる終了Izumi Tsutsui2017-01-08

操作
ブロック元 致命的 #995: CPU使用率が常に100%になり、メモリを大量に確保しつづけることがある終了toshi_a 初音2017-03-16

操作

Osamu Koga さんが7年以上前に更新

  • プラグイン名followingcontrol にセット

このチケット自体と直接的な関係はなさそうですが、設定画面でパラメータをいじって試した所、followingcontrolのon_periodが倍速で発火しているっぽい事が分かりました(followingsの取得間隔を10分、followersを17分に設定したところ、それぞれ最短の間隔が5分と9分になった)。on_periodがおかしいのか、followingcontrol固有の問題なのかはまだ調べていません。

Osamu Koga さんが7年以上前に更新

  • 関連している バグ #932: periodイベントが2回発火している を追加

toshi_a 初音 さんが約7年前に更新

  • 関連している 致命的 #964: フォロー・フォロワータブで何も表示されていない行をクリックすると落ちる を追加

toshi_a 初音 さんが約7年前に更新

#964 の修正によって、メモリ上にUserが存在しないユーザはfollowingcontrolが無視してしまうということがわかりました。
メモリ上に確保された後、フォロー・フォロワーのクロールが行われると、Userインスタンスの取得に成功するので、新たにタイムラインに出現したユーザとのフォロー関係がその時に構築されたものであると誤検出するようです。

toshi_a 初音 さんが約7年前に更新

どうやら、フォロイー・フォロワーを取得する時に使っているDeferred.whenが、特定の条件下で引数のDeferredがすべて終了しても、次が実行されない問題があるらしい(Thread周り?)。

バグを直すことももちろんだが、ネットワークアクセスの処理などの場合、タイムアウトがあったほうが便利そうなので、前のジョブが一定期間経ったら失敗するようなDeferredユーティリティがほしいとも思った。

toshi_a 初音 さんが約7年前に更新

  • ステータス新規 から 実装待ち に変更
  • 担当者toshi_a 初音 にセット

mikutter側のユーザを取得する処理にも問題がありました(bee6c2f5)。

本筋とは関係がありませんが、変更の規模が小規模なのと、流石に実用に耐えないレベルの影響だったため、以下の問題も修正しました。

しかし単に修正すると、プロフィールタブのフォロイー、フォロワーを開いた時、その数だけ画像のロードが始まります。
そのことによってmikutter 3.5では、以下の問題が発生しました。

  • 他の画像がロードされるのが遅くなる #934 (ce9d31ed) によって、同時にダウンロードする画像点数が4枚までとなったため、それが終わるまでほかの画像がロードされなくなります。
  • CPU使用率が長時間100%となる 以前もあったが、画像のロードが高速で終わる場合、画像ロード時の負荷が若干上がっているため長時間負荷が高い状態になる

そもそもフォロイー・フォロワーは表示されているぶんだけ画像を読み込めば良くて、ダウンロードのオーバーヘッドが気になるほど大量の画像をロードすることに問題があると考えて、行が表示された瞬間に、その行についてだけアイコンをダウンロードする変更 c2ce3ceb を適用しました。

toshi_a 初音 さんがほぼ7年前に更新

  • ブロック元 致命的 #995: CPU使用率が常に100%になり、メモリを大量に確保しつづけることがある を追加

Izumi Tsutsui さんが6年以上前に更新

3.6.0 対応メモ

  • bee6c2f5 は mikutwitter が Twitter plugin 以下に移動したこと、 Retriever を使っていることから一部修正要
  • c2ce3ceb は develop にもそのままマージ可能

上記修正を 3.6.0-develop に当てると、このチケットの問題(フォロー通知が大量に流れる)は修正されているように見えます。

toshi_a 初音 さんが約6年前に更新

  • ステータス実装待ち から レビュー待ち に変更
  • 担当者toshi_a 初音 から Izumi Tsutsui に変更
  • ブランチtopic/916-follow-notification-for-3.6 にセット

3.6.4にrebaseした新しいブランチを作って、3.6用の手直しを入れました。

それで試してみたところちゃんと動いているようなのですが、テスト用アカウントではフォロー・フォロワー数が少なく検証にならず、toshi_aは凍結されていてフォロー・フォロワーリストが取得できなかったため、そちらで確認してもらいたいです。

この問題は最近はつついさんのほうが見てくれていると思うので、つついさんにレビューお願いします。

(先日から若干運用を変えて、ステータスを「マージ待ち」か「まだダメ」に変えてもらうようにしています。)

Izumi Tsutsui さんが約6年前に更新

topic/916-follow-notification-for-3.6 を checkout してテストしました。
起動直後からフォロー・フォロワーとも表示されているので問題ないと思います。
ちょくちょく error になっているアイコンがありますが、これは twitter側の問題ですかね

Izumi Tsutsui さんが約6年前に更新

  • 担当者Izumi Tsutsui から toshi_a 初音 に変更

toshi_a 初音 さんが約6年前に更新

  • ステータスマージ待ち から 終了 に変更

master にmergeしました

他の形式にエクスポート: Atom PDF