レイジーロードまたはパフォーマンス向上のための努力なし

Question

システムのパフォーマンスを向上させるために、レイジーローディングの使用をボード全体で使用する必要があることが示唆されています。これは、 "mappedBy"プロパティを持つOneToOneマッピングを@OneToManyマッピングに変更することです。これは、データベースからの不要なデータのロードを処理し、アプリケーションの処理速度を低下させることになります。

複数層システム（基本的に2層）を実行します。フロントエンドにはJSFを使用し、バックエンドにはビジネス・アクセス・レイヤーとデータベース・アクセス・レイヤーが含まれています。フロントとバックは、EJBのビューを通信しますが、EJBには実際のロジックがありません。他の技術が使用されている - 春と休止状態

ここで、トピックを少し読んだら、lazingローディングの使い方は、正しく適用する必要があるという点で銀色の弾丸ではないようです。遅延読み込みのたびに、データをフェッチするためにSelect文が発行されます。フロントエンドが遅延ロードされるプロパティにアクセスし、バックエンドでセッション/接続が閉じられると、nullが返されるという問題もあります。

上記の問題は正しいですか？

レイジーローディングソリューションやパフォーマンスの向上を実現するには、どのようなアプローチや方法が最適ですか？可能であれば、データモデルをやり直すことではありません。

DBAグループと協力して、2つのシステム間で起こっていること、つまりクエリの見方、データの使用方法などを理想的に把握することができましたが、トラブルスポットを特定し、Hibernateオブジェクト/それを改善するための最良の方法を知るための質問。また、フロントエンドを見て、どのようにデータが表示されるように背面から前面に渡されるかを決定する。

良いアプローチ/他のアプローチ？

Answer 1

高価な操作を遅らせるにはレイジーローディングが最適ですが、すべてのパフォーマンスの問題を解決するための銀色の弾丸ではないという結論に同意します。

まず、実際のパフォーマンスの問題がどこにあるのかを分析するために、まず分析を行ってください。一部のデータを遅延ロードすることは良い解決策になるか、まったく異なるものになる可能性があります。プロファイリングを開始してアプリ内で何が起こっているのかを分析するまでは、実際にはわからない方法があります。

Answer 2

最初に行うべきことは、アプリケーションを測定して、パフォーマンスの問題の原因を正確に突き止めることです。

JProfilerのようなツールを使用して、問題の原因を特定します。

あなたは何が起こっているかを知ったら、それをどのように修正するかを決めることができます。

パフォーマンスの問題を引き起こす原因を知らずに遅延読み込みスキームを実装することは、時間の無駄になります。

あなたの問題がどこにあるのかを知ったら、あなたのスキーマ/クエリを改善することができるかどうかを調べることができます。

Answer 3

それはあなたがやろうとしていること、言いにくいことに大きく依存します。あなたのDBAに行くというあなたの考えは、確かに生産的である可能性があります。人々ができる唯一のことは、いくつかの例を提供することです。私の場合：

遅延ロードは、次のような状況で私たちにとって大きなパフォーマンス改善でした。さまざまなレベルの15,000ノードの巨大な木がありました。もともと私たちはツリー全体をロードしてレンダリングしようとしました。それは年を取った。ユーザーがノードを展開したときにのみ、ブランチを遅延ロードするようにコードを変更しました。ノードの拡張には少し時間がかかりますが、アプリケーション全体がより速く感じられます。この場合、マッピングを変更することは理にかなっています

ここで、ビジネスロジックで必要とされるため、ツリー全体を処理する必要がある場合は、遅延読み込みの違いはほとんどありません。この場合、マッピングを変更するだけでは解決策はなく、さらに高価になる可能性もあります。

アプリケーションが何をしているのか、何が遅いのか、何を達成しようとしているのか、少し考える必要があります。プロファイラーを引き出すことは、銀色の弾丸でもありません。

アプリケーションの特定の例がなければ、遅延読み込みが有用かどうかを言うことは意味がありません。

Answer 4

データのフェッチによってロード時間が遅くなる場合は、遅延ロードが最適なソリューションです。しかし、それをボード全体に適用することは早すぎる最適化のようです。あなたはおそらく、各データセットのためにそれを意図して、それがアプリケーションをスピードアップするかどうかをテストしたいと思うでしょう。もしそうでなければ、それは遅延ロードのための良い候補ではありません。

私が遅延ロードを実装した方法では、データ層に変更はありませんでした。それは、ビジネスロジックとプレゼンテーションコントローラのすべてでありました。私はEJBに慣れていないので、これはあなたのJavaアプリケーションで動作すると仮定します。いずれにしても、遅延ロードを実装するときは、必要になるまでデータがロードされません（レイジーにロードするデータはありません）。次に、データ層を呼び出して自分のデータ（またはデータのサブセット）を取得します。

接続の問題については、データ接続をテストして閉じているかどうかを確認する必要があります。つまり、データ接続をプールしていますか？接続が閉じている場合は、再度開きます。しかし、実際の遅延ロードの実装と同様に、これはフロントエンドではなくロジッククラスで行う必要があるため、この機能を何度も複製する必要はありません。