プロジェクト

全般

プロフィール

バグ #916

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

Osamu Koga1年以上前に追加. 3ヶ月前に更新.

ステータス:
終了
優先度:
通常
担当者:
対象バージョン:
プラグイン名:
followingcontrol
ブランチ:
topic/916-follow-notification-for-3.6
クラッシュする:
いいえ

説明

詳細はよく分からないですが、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回発火している終了2016-11-14
関連している 致命的 #964: フォロー・フォロワータブで何も表示されていない行をクリックすると落ちる終了2017-01-08

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

関係しているリビジョン

リビジョン b61c9085 (差分)
toshi_a 初音約1年前に追加

フォロイー・フォロワーが取得できたかどうかがわからないので、デバッグ出力を追加 refs #916

リビジョン bee6c2f5 (差分)
toshi_a 初音約1年前に追加

Twitter: ユーザIDをユーザに変換する処理の効率化 refs #916

キャッシュ等から取得できなかったユーザだけをTwitter APIにリクエストす
るようにした。

リビジョン c2ce3ceb (差分)
toshi_a 初音約1年前に追加

Gtk::UserListのアイコンのロードを、行が表示されるまで遅らせる refs #916

リビジョン 2a2926b4 (差分)
toshi_a 初音3ヶ月前に追加

フォロイー・フォロワーが取得できたかどうかがわからないので、デバッグ出力を追加 refs #916

リビジョン 34c9586a (差分)
toshi_a 初音3ヶ月前に追加

Twitter: ユーザIDをユーザに変換する処理の効率化 refs #916

キャッシュ等から取得できなかったユーザだけをTwitter APIにリクエストす
るようにした。

リビジョン eb470a58 (差分)
toshi_a 初音3ヶ月前に追加

Gtk::UserListのアイコンのロードを、行が表示されるまで遅らせる refs #916

履歴

#1 Osamu Koga1年以上前に更新

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

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

#2 Osamu Koga1年以上前に更新

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

#3 toshi_a 初音1年以上前に更新

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

#4 toshi_a 初音1年以上前に更新

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

#5 toshi_a 初音約1年前に更新

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

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

#6 toshi_a 初音約1年前に更新

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

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

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

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

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

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

#7 toshi_a 初音約1年前に更新

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

#8 Izumi Tsutsui5ヶ月前に更新

3.6.0 対応メモ

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

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

#9 toshi_a 初音3ヶ月前に更新

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

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

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

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

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

#10 Izumi Tsutsui3ヶ月前に更新

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

#11 Izumi Tsutsui3ヶ月前に更新

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

#12 toshi_a 初音3ヶ月前に更新

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

master にmergeしました

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