こんにちは、
私は大学で Hibernate と JDBC を比較するための検索を作成しています。この作業の主な焦点はパフォーマンスです。
私が請求されている質問の 1 つは、これらのパフォーマンス テストをどのように実施するかに関するものです。
ええと、これは簡単に言えば、データ X を探すことを目的としたデータベースへのクエリを作成する 2 つのメソッドを所有する私の仕事です。これらのクエリは hibernate と jdbc で記述され、そこから両方のテストを実行します。
これらのテストがどのくらいの頻度で実行され、どのように評価されているか教えていただけますか? どのようなツールが使用されていますか? 検索すると、jdk に付属する JConsole というツールが見つかりました。このツールで問題を解決できると思いますか?
ありがとうございました：]
いくつかの理由から、この質問を閉じることに投票します。しかし、これは非常に頻繁に持ち込まれるテーマなので、特に、私は日常業務の一環として Hibernate のいくつかのパフォーマンス測定を考え、実行することに時間を費やしたので、答えざるを得ないと感じています。
Hibernate のパフォーマンス テストやベンチマーク、またはデータベースに関連するものを実行することは非常にトリッキーであり、解決すべき現実の問題がある環境 (つまり、既存のアプリケーション) でのみ実行する必要があります。合成ベンチマークは、より多くの聴衆に十分な回答を提供しないため、通常はほとんど役に立ちません。これは学術的な経験であり、そのように見なされるべきであることを理解しています:-) 私が経験した主な問題をリストアップしようとします:
1) Hibernate は速すぎて正確に測定できません。ほとんどの時間はネットワークとデータベース自体に費やされるため、Hibernate に費やされた時間だけを測定することは非常に困難です。ByteMan ( http://jboss.org/byteman ) を使用してバイトコードを強化し、正確なタイミングを抽出するなど、一連のトリックを使用してこれを抽出しました。私が測定した操作のほとんどは、数ミリ秒しかかかりませんでした。これは、マシンのわずかな外乱でさえ、結果に大きな変化をもたらしたことを意味します。したがって、標準偏差に注意し、「最良の結果」と「最も悪い結果」のかなりの部分を破棄します (私の提案はそれぞれ 20% で、中間の 60% になります)。
2) ローカル データベースと別のマシンのデータベースのどちらを使用するかを選択するのは困難です。その理由は、Hibernate を測定するのではなく、ローカル データベースを使用する場合はオペレーティング システムのスケジューラと IO を測定するか、別のマシンでデータベースを使用する場合はネットワーク パフォーマンスを測定することになるためです。
3) Java HotSpot VM はバイトコードの多くのインライン化を行い、使用するほど最適化します。そのため、実際のタイミングを取る前に VM を「ウォームアップ」する必要があります。パフォーマンス テストを 10 分間実行し、数千回の操作のみを実行すると、ソフトウェアを可能な限り最高のパフォーマンスで測定できなくなる可能性があります。それで、それを数時間実行します。または、それぞれ異なる時間数でいくつかのテストを実行することをお勧めします。4 時間、8 時間、および 16 時間が適切な候補になります。
4) 引き続き「可能な限り最高のパフォーマンス」のトピックでは、Hibernate を使用法に合わせて微調整する必要があります。たとえば、Hibernate を実行しているホストに大量のメモリと高速な CPU があり、別のマシンでデータベースを使用することを選択した場合、キャッシュの選択によって Hibernate のパフォーマンスが向上する可能性があります。そして、このシナリオでキャッシュを使用しないことは現実的ではありません;-) また、シナリオによっては、キャッシュが実際に害を及ぼす可能性があります。そのため、Hibernate の第 2 レベルのキャッシュがどのように機能するかについて十分な知識が必要です。
5) キャッシングについて: Hibernate には、第 1 レベルのキャッシングと第 2 レベルのキャッシングがあります。キャッシュを使用するかどうかの選択も、最終結果に影響します。接続プーリングについても同様です。Hibernate には、本番環境では使用しない内部接続プーリング メカニズムが付属しています。したがって、まったく使用すべきではないコンポーネントを測定することになります。一方、JDBC テスト用に独自のキャッシングまたは接続プール メカニズムを実装することはおそらくないでしょう。補足: 実際の Java EE アプリケーションでは、アプリケーション サーバーの接続プールを使用するように Hibernate を構成する必要があります。
6) クエリのバッチ処理 (たとえば、多数の挿入を行う場合) など、現実の世界で Hibernate によって使用される可能性のある JDBC 機能にも注意する必要があります。このオプションでは、Hibernate を調整して調整する必要がある場合があります。「純粋な JDBC」テストにもこれを実装する必要があります。また、RDMBS によっては他のものよりもうまく機能するオプションがあることに注意してください。
7) ハードウェア: ローカル マシンでの実行は、実際のサーバーでの実行とはまったく異なります。個人的には、Amazon の Linux を使用して、Amazon EC2 のいくつかのインスタンス タイプで実行することをお勧めします。このようにして、他の関係者が簡単に再現できます。ただし、仮想マシン固有の遅延にも注意してください。ポイント 1 の上下 20% を破棄することで、これを処理できます。
幸運を！
jConsole を使用すると、CPU 使用率やメモリ使用率など、アプリケーションが使用しているリソースを確認できます。これらの呼び出しをテストしようとしているメトリックの種類は何ですか? 使用されているリソースの量を確認しようとしていますか、それとも単に全体的な速度をテストしようとしていますか?