事前ロードされたデータによる問題で読み込みが10倍遅くなる

サポート
1

私たちは、data-preloadedのトラッキング状態が特に信頼レベル3または4、または長期間アクティブなユーザーに対して非常に長いことに気づきました。

ユーザーのトピックトラッキング状態をデータベースから削除したり、または上記のクエリから削除または制限したりすることは、何らかのダメージを与えるでしょうか？例えば、バッジや信頼レベルを奪うなどです。

3

This image displays a performance analysis report detailing the load times for various Ruby on Rails application classes in a Linux command-line interface. (Captioned by AI)
This image displays a performance analysis report detailing the load times for various Ruby on Rails application classes in a Linux command-line interface. (Captioned by AI)1958×566 108 KB

同様の問題が発生し、トピック追跡状態のクエリがホームページのレンダリング時間の約70%を消費していました。高負荷時には、このクエリの完了に1000ミリ秒以上かかることもあります。

トピック追跡状態を非同期リクエストにする（オプションの）アプローチがあれば、ユーザーはホームページをより迅速に表示できるはずだと考えます。

「いいね！」 1
4

その通りです！最大3000msまで見たことがあります

5

この行を削除するだけです。

# report = TopicTrackingState.report(@guardian: user) # serializer = TopicTrackingStateSerializer.new(report, scope: @guardian, root: false) serializer = TopicTrackingStateSerializer.new(}${{ scope: '@guardian', root: false }}) hash = serializer.as_json (AIによるキャプション)
# report = TopicTrackingState.report(@guardian: user) # serializer = TopicTrackingStateSerializer.new(report, scope: @guardian, root: false) serializer = TopicTrackingStateSerializer.new(}${{ scope: '@guardian', root: false }}) hash = serializer.as_json (AIによるキャプション)1929×185 43.7 KB

フロントエンドコードを調べた後、私の行動が潜在的に問題を引き起こした可能性があると推測しました。しかし、実際には、その行を削除してサーバーをリロードした後、顕著な違いは見られず、ホームページの読み込み時間は約60％短縮されました。

これは、同様のパフォーマンスの課題に直面している人々のための小さな経験則です。それにもかかわらず、この行動の結果を保証することはできないため、自己責任で進めてください。

6

私も同じ動作を確認しました