O/Rマッピングの導入効果を測る：Hibernateで理解するO/Rマッピング（6）（1/3 ページ）

　新たなフレームワークを開発現場で導入する際には、たいていの場合「懸念」が先立ちます。O/Rマッピングに限らず、フレームワークを導入するに当たっては以下のようなポイントが懸念されるようです。

　開発現場で新しいフレームワークの導入を検討しているアーキテクトにとって、関係者の「懸念」を取り除き、理解を得るのが最初の関門です。特に上記のポイントは誰もが気になる部分であり、説得力のある説明を要求されるでしょう。

　最終回は、こういったO/Rマッピング導入時の懸念事項の解決を中心にHibernateの解説を行い、O/Rマッピングフレームワークを導入する際の判断材料にしたいと思います。

Hibernateのパフォーマンスをテストする

　データアクセスはパフォーマンスのボトルネックになりやすい部分です。そしてデータアクセス部分を担当するO/Rマッピングフレームワークは、パフォーマンスに与える影響において最も気になるポイントの1つでしょう。実際、著者はこの連載の当初から、ある知人に「ほかのデータアクセスソリューションとのパフォーマンスの比較をぜひやってほしい」といわれていました。

　このご要望に応えて、今回はHibernateとJDBCおよびCMPとのパフォーマンスを比較する簡単なテストを行ってみることにします。ただし注意していただきたいのは、この結果が必ずしもそれぞれのソリューションの絶対的な「能力値」や「能力差」にはならないということです。あくまでHibernateの導入に当たってパフォーマンスに関する漠然とした懸念を取り払うためだけの指標だと考えてください。また、テストの方法は簡単なものなので、実際に動作させる環境で、納得のゆく結果を得るために自分で試してみることをお勧めします。

パフォーマンステストの環境準備

　今回のテストではJakarta Projectが提供している「JMeter」というツールを利用します。JMeterはフリーで提供されており、GUIベースの簡単な操作で自由度の高いパフォーマンステストが実行できます。JMeterのサイトから製品をダウンロードしてください（本稿では、Zip版のバージョン2.0.1を使用します）。

　圧縮ファイルを解凍するだけで準備完了です。/bin/jmeter.batを実行すればGUIベースのJMeterが起動します。今回のパフォーマンステストは、以下の環境で行っています。

　テスト用に、本連載の第5回「リレーショナルデータにおけるメリットを体験」で使用したHibernateのJoinサンプルを利用して以下のような結果を返すサーブレットを用意しました。

画面1　テスト用のサーブレット画面

　上記のHibernateのサーブレットと同じデータを取得するように、JDBCおよびCMPを使ってロジックを実装します。そしてHibernateで作成したサーブレットと同じ結果を返すようにJDBC用、CMP用それぞれのサーブレットを作成してデプロイします。なお、CMPはEJB 2.1のローカルEJBを使用し、CMRを利用してリレーショナルデータを取得しています。

JMeterの設定

　JMeterを立ち上げるとテスト計画とワークベンチという2つのノードだけが表示されたツリービューが現れます。まずは、［テスト計画］ノードで右クリックして［追加］→［スレッドグループ］を選択してスレッドグループを作成します。

画面2　スレッドグループの設定

　今回のテストでは、画面2のようにスレッドグループを作成し、10スレッドを200回ループさせるように設定しました。

　続いて、この［スレッドグループ］の子ノードとして［HTTPリクエスト］サンプラーを追加します（スレッドグループのノード上で右クリックし、［追加］→［サンプラー］→［HTTPリクエスト］を選択してください）。［HTTPリクエスト］ノードで、サーブレットへのリクエストを設定します。

画面3　HTTPリクエストサンプラーの設定

　同じくスレッドグループの子ノードとして［統計レポート］リスナーを追加します。この［統計レポート］リスナーに実行結果がリアルタイムに表示されます。

画面4　統計レポートリスナー

テスト実行

　では、テストの開始です。メインメニューの［実行］でテストを開始し、カウンタが停止するまで待って［統計レポート］の値を確認し、書き残しておきます。1つのソリューションでのテストが終われば、［HTTPリクエスト］サンプラーのパスを、次のソリューションで作成したアプリケーションのパスに書き換え、メインメニューの［実行］→［すべて消去］で結果をクリアします。

　実験の結果、3つのソリューションのテスト結果は表1のようになりました。

　Hibernateのパフォーマンスは、1回の処理にかかる「平均時間」「最低時間」「最大時間」ともに、わずかながらほかのソリューションを上回っていました。

　表のデータの中にある「スループット」とは、単位時間内（このテストの場合1秒間）に処理できる情報量を表しています。またローカルアクセスが可能になったCMPは非常にパフォーマンスが良いという結果が出ました。HibernateはCMPの次に高いスループットを示しています。

　CMPやHibernateはキャッシュの仕組みが備わっているため、ネイティブなJDBCへのアクセスよりも高いパフォーマンスを示しています。さらに今回使用したJDBCのサンプルは非常に単純な実装でパフォーマンスを考慮した実装にはなっていません。そのうえ、今回のテストはキャッシュの恩恵が受けやすい状況なので、一概にJDBCよりもHibernateやCMPの方が、パフォーマンスが良いとはいえません。テストの環境やプログラムの作成方法、クエリの複雑さなどによって、実験結果は大きく変わってくることでしょう。

　重ねていいますが、このテスト結果が各ソリューションの絶対的なパフォーマンスの能力値を示しているわけではありません。しかしこの結果によって、HibernateがJDBCやローカルのCMPにパフォーマンス面で遜色がないどころか、ほかのソリューションを凌駕するほどのパフォーマンスを示し得ることがご理解いただけると思います。