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

O/Rマッピングは、従来の煩雑なデータベースに関する処理の記述をスマートにし、柔軟なアプリケーションの構築を可能にします。本連載ではオープンソースのO/Rマッピングフレームワーク「Hibernate」を用いてO/Rマッピングの基礎を解説します。そしてさらに、J2EEアプリケーションへの実践的な適用方法とそのメリットも紹介していきます。（編集局）

[山本大，株式会社クロノス]

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

• パフォーマンス
• 開発効率
• API習得効率

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

　最終回は、こういった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が起動します。今回のパフォーマンステストは、以下の環境で行っています。

環境／ソフトウェア	スペック／バージョン
PC	ThinkPad R40e
CPU	Celeron 1.79GHz
メモリ	497MBytes
OS	Windows XP Professional
アプリケーション・サーバ	JBos 3.2.3
RDBMS	MySql 4.0.20
表1　テスト環境

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

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

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

注：Hibernateは1度目のアクセスでSessionFactoryの生成を行います。この処理は起動時に1度だけ行えばよい処理ですが、コストが高い処理であるため、テストに当たっては前もってSessionFactoryの生成を行っておくことにします。

JMeterの設定

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

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

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

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

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

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

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

テスト実行

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

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

列名	カウント	平均 （ミリ秒）	最低 （ミリ秒）	最大 （ミリ秒）	エラー率	スループット
Hibernate	2000	384	30	1222	0.00％	25.2/秒
CMP（CMR）	2000	387	40	2654	0.00％	25.3/秒
JDBC	2000	409	120	1542	0.00％	24.2/秒
表1　パフォーマンステストの結果一覧。１秒当たりの処理数でも、他ソリューションに遜色のないパフォーマンスが出た

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

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

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

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