-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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.
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
リアクションをポーリングで取得するオプション #11090
Comments
そのついたリアクション数 x 連合インスタンス数 分のdeliverと他のサーバーのinbox処理が発生するのもどうにかしたいわ。 |
ちょっとわがままなお願いなのですが、ノートをタイムラインが流れながらもすごい勢いでいろいろなリアクションがついていくのを眺めるのが好きなので、ポーリングの間隔は最初が短めなのがだんだん長くなるとか、リアクションがリアルタイムでついているかのように差分の更新が再生されるなどの仕組みがあると嬉しいです。(新しい種類のリアクションがついたとき、そのリアクションが最初についた時刻もデータに含まれていて、それを考慮した表示にするとよりリアルな感じになるかも。) あとポーリングというより、一定期間ためた情報を定期的にプッシュする方がパフォーマンス的に良いかも。 |
時刻情報を含めると、『「どのリアクションがいくつか」という情報ひとつだけで済む』が実現できず、「ストリーミングで100個リアクション情報が流れてくる」とデータ量的には変わらなくなりそうな気がしている |
ちょっと冗長に書きますが
というデータを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 すべき |
Summary
例えば1秒間に100個くらいリアクションが付く場合、ストリーミングで100個リアクション情報が流れてくるためとても無駄がある
ポーリングにすれば「どのリアクションがいくつか」という情報ひとつだけで済むためパフォーマンスが改善できそう
The text was updated successfully, but these errors were encountered: