2016-04-05 11 views
3

React、Redux、およびWebsocketを使用して「リアルタイム」Webアプリケーションを実装/評価しています。サーバー上では、毎秒約32回の割合でデータセットに変更が発生しています。私はReact Reduxアプリケーションの状態変化の割合に注意する必要がありますか?

それぞれの変更により、Websocketを使用してアプリケーションに非同期メッセージが送信されます。非同期メッセージは、私の還元状態でRECEIVEアクションを開始します。状態の変更はコンポーネントレンダリングにつながります。

私の関心は、状態変化の頻度は、クライアント上の容認できない負荷につながるということですが、私はなど

ときでしょうこの、メッセージの数、構成部品の数に対して負荷を特徴付けするかどうかはわかりません問題になるか、それが問題であるかを把握するためにどのようなツールを使用しますか?

私の状態の "形状"はレンダリングのパフォーマンスに違いがありますか?低い変更オブジェクトを別のエンティティに配置しながら、高い変更オブジェクトを1つのエンティティに配置することを検討する必要がありますか?

変更イベントをバッチ処理して、個々の変更ではなく変更のリストに応答できるようにする必要があります(効果的に状態の変化率が低下します)。

私は何か提案をいただきありがとうございます。

答えて

0

これは実際には尋ねるにはかなり妥当な質問であり、はい、それらはすべて見て良いアプローチのように聞こえる。

あなたのサーバー側のデータ変更は1秒間に32回発生していると思います。その情報そのものを一括処理できますか?文字通りすべての単一の更新を表示する必要がありますか?

"scaling"reducing the number of store subscription updatesの回答を含むRedux FAQの「パフォーマンス」セクションに興味があるかもしれません。

状態を更新頻度に基づいて部分的にグループ化することは良いアイデアのように聞こえます。そのチャンクに登録されていないコンポーネントは、React Reduxに組み込まれている浅い等価性チェックに基づいて更新をスキップできる必要があります。

私はパフォーマンス関連の情報とライブラリのためのいくつかの便利なリンクを追加します。 My React/ReduxリンクレポのセクションはReact performanceで、Reduxライブラリのリンクレポはstore change subscriptionscomponent update monitoringという関連セクションがあります。

+0

ありがとうございます!リンクはちょうど私が必要としたものでした。 –

関連する問題