RequestFactory と GWT のパフォーマンスについて質問があります。約 1000 の EntityProxies を返す 8 つのフィールドを持つドメイン エンティティがあります。リクエストが発生してから応答するまでの時間は約 20 秒です。同じことを行いますが、10 個の EntityProxies を返し、時間は 17 秒で、ほぼ同じです。
これは私が開発モードで作業しているためですか、それともコードを Web にリリースするときの時間は同じになりますか?
パフォーマンスを向上させる方法はありますか？、私はデータを読んでいるだけなので、おそらく読み取りだけで書き込みはしない何かが解決策になるでしょうか？
私はこの投稿を私の問題に似たもので読みました:
GWT Requestfactory のパフォーマンスに関する提案
どうもありがとう。
PD: サーバーで xml を作成し、それをクライアントに送信して、そこでオブジェクトを再作成することが 1 つの解決策になる可能性があることをどこかで読みましたが、アプリの設計が実際に変更されるため、これを実行したくありません。
助けてくれてありがとう、おそらく Request Factory を使用して何千ものレコードを取得するのは間違いだったことに気づきました。
この投稿に従って、最初に Locator を使用して isLive() および Find() メソッドをオーバーライドしました: gwt-requestfactory-performance-suggestions
応答時間は約 13 秒に短縮されましたが、それでも高すぎます。
しかし、私はそれを簡単に解決しました。1000+ Entities を返す代わりに、各フィールドがすべて同じフィールド レコード (1000+) を区切り記号で連結した新しいデータベース テーブルを作成しました (各 db フィールドの長さは約 10000 です)。テーブルには 1 つのレコードしかありません。約8フィールド。
このようなもの：
Field1 | Field2 | Field3
Field1val;Field1val;Field1val;....... | Field2val;Field2val;Field2val;...... | Field3val;Field3val;Field3val;......
その One レコードを RequestFactory を介してクライアントに返すと、速度が大幅に低下しました!約 1 秒です。クライアントでこの大きな文字列を解析すると、その期間は約 500 ミリ秒です。したがって、約 20 秒を無駄にする代わりに、同じことを達成するのに約 1 ～ 2 秒かかります。
ちなみに、私は情報を表示しているだけなので、レコードを挿入、削除、または更新する必要はないので、このソリューションは私にとってはうまくいきます。
この解決策を共有できると思いました。
次のステップにどれだけの時間が費やされたかを調べるために、アプリをプロファイリングする必要があります。
RequestFactory :とAutoBeanそれぞれがリフレクションに依存しているため、ここにはオーバーヘッドがあります。クライアントに表示する予定のエンティティのみを送信することもできます。レイテンシを大幅に削減するもう 1 つの最適化は、isLiveメソッドをオーバーライドしてtrueEntitiyLocatorを返すことです。パフォーマンスを向上させる 1 つの方法は、キャッシュを使用することです。HTML5localstorageを使用して、クライアントでデータをキャッシュできます。これは、頻繁に変更されないデータに特に当てはまります。
GWT でのパフォーマンス プロファイリングと問題の修正には注意が必要です。GWT Hosted モードでのすべてのプロファイリングを回避します。それらは有用なことを意味するものではありません。
WEB モードでのみプロファイリングする必要があります。
GWT RequestFactory は、設計上、GWT RPC や GWT JSON などよりも低速です。これは、デルタを計算し、保存時に少量の情報のみをサーバーに送信する GWT RF 機能とのトレードオフです。
何千ものプロキシをロードしないように、アプリケーションの設計を再確認する必要があります。RF は、「フォーム」のようなアプリケーションを意味します。何千ものプロキシが必要になる唯一の理由は、グリッド表示のためです。そのシナリオでは、おそらくページ分割された非同期グリッドを使用できます。