misskey-dev
リアクションをポーリングで取得するオプション
Summary
例えば1秒間に100個くらいリアクションが付く場合、ストリーミングで100個リアクション情報が流れてくるためとても無駄がある ポーリングにすれば「どのリアクションがいくつか」という情報ひとつだけで済むためパフォーマンスが改善できそう
1秒間に100個くらいリアクションが付く場合
そのついたリアクション数 x 連合インスタンス数 分のdeliverと他のサーバーのinbox処理が発生するのもどうにかしたいわ。
ちょっとわがままなお願いなのですが、ノートをタイムラインが流れながらもすごい勢いでいろいろなリアクションがついていくのを眺めるのが好きなので、ポーリングの間隔は最初が短めなのがだんだん長くなるとか、リアクションがリアルタイムでついているかのように差分の更新が再生されるなどの仕組みがあると嬉しいです。（新しい種類のリアクションがついたとき、そのリアクションが最初についた時刻もデータに含まれていて、それを考慮した表示にするとよりリアルな感じになるかも。）
あとポーリングというより、一定期間ためた情報を定期的にプッシュする方がパフォーマンス的に良いかも。
時刻情報を含めると、『「どのリアクションがいくつか」という情報ひとつだけで済む』が実現できず、「ストリーミングで100個リアクション情報が流れてくる」とデータ量的には変わらなくなりそうな気がしている
ちょっと冗長に書きますが
{igyo: {firstReaction: 03:34:00.00, count: 24},
super_igyo: {firstReaction: 03:34:00.50, count: 9}
ultra_igyo: {firstReaction: 03:34:01.00, count: 2}}
というデータを03:34:02.00に受け取ると、3:34:02.00～34:34:04.00の間に秒速12で偉業スタンプが、3:34:02.50～34:34:04.00の間に秒速6でスーパー偉業スタンプが、3:34:03.00～34:34:04.00の間に秒速2でウルトラ偉業スタンプが、みたいなイメージです。あくまでリアリティを増すための一案で、実装してみたらいまいちかもしれませんが。
フォロワー数が少ないユーザーの場合はリアクションが大量につくことは少ないだろうから、フォロワー数が一定以上のユーザーの投稿だけポーリングにするとか、そういうヒューリスティックは要るかも
あーでもリアクションが付くことが少ないTLの場合ポーリングにするとむしろ通信量は増加する可能性があるな
ポーリングじゃなくて WebSocket の送出側が debounce すべき
