SQL呼び出しの回数を削減する

   エンティティBeanを素直に使ってシステム開発を行うと、RDBに対するSQLの呼び出し回数が爆発的に多くなってしまう場合があります。

   例えばエンティティBeanにて、発注伝票オブジェクトの中に明細オブジェクトがコレクションとして入っている様なケースを見てみます。1月分の発注伝票を検索し、その明細を全部表示させるようなコーディングを書くと、発注伝票の数だけ明細を取得するSQLをひとつずつ発行してしまいます。

   SQLの呼び出し回数を減らす手段としては、JBoss独自の設定にて「先読み」「遅延読み込み」（※注3）等を利用する方法と、JDBCなどを使って直接（効率良く）データを取得する方法があります。エンティティBeanを使っている箇所がパフォーマンス上のボトルネックとなっている場合は、その部分だけJDBCで実装し直すことも考えてみるべきでしょう。

※注3： CMPに対してread-ahead（on-load、on-fine、none）、eager-loading、lazy-loadingといった設定をすることにより可能となります。

Hibernateを使用する

   エンティティBeanは煩雑で、パフォーマンス上の問題を引き起こしやすいため、最近は敬遠されることが多いようです。そういった状況に対応して、JBossではHibernateを標準でバンドルするようになりました。つまり、 TomcatのようにHibernateがMBeanでラッピングされ、JBossの1サービスとして動作します。

   Hibernateとはオブジェクト／リレーショナルマッピングツールと呼ばれるもので、エンティティBeanが実現しようとしている機能とほぼ同じことが実現できます。JBossのトランザクションマネージャとの連動、JBoss Cacheの利用といったことも可能となっています。また互換性に関しても、各種J2EEのAPサーバとの互換を考慮するよりも、Hibernate対応のアプリケーションを構築した方が（少なくとも現時点では）互換性が高いともいわれています。

   HibernateはエンティティBeanよりも柔軟な調整が行えますので、より細かいチューニングが行え、また、RDBの持っている機能を有効に利用できます。

   さらに、次期EJB 3.0の仕様ではHibernateが採用しているモデルがほぼそのままEJB 3.0の仕様として採用される見込みです。EJB 3.0への移行を考慮するのであれば、Hibernateは良い選択肢だと思われます。

参照サイトと更新サイトとを分離する

   この方法はJBoss内部のキャッシュを最大限有効活用させようとするための手法です。JBossはトランザクションのコミットオプションをAにすることで、データを更新するとき以外データベースからのデータを再読み込みしません。そのために非常にパフォーマンスが向上します。しかしながら、実際には参照だけ行えばよい、というアプリケーションはめったに存在しません。多くの場合はデータの更新を伴ってはじめて意味をなす処理となります。

   キャッシュを最大限利用しつつ更新も可能とするために、参照専用サイトと更新専用サイトを別々に用意します。一般的には参照用サーバを複数台、更新用サーバを1台（1クラスタ構成）とします。更新が発生して、参照専用サーバ内のキャッシュ内のデータも更新したい場合は、参照専用のサーバに対して「キャッシュ情報を無効にせよ」というように通知することができます。

   これはJBossでは「cache-invalidation-service」と呼ばれ、あらかじめそのためのサービスがdeployディレクトリに用意されています。このしくみは、JMSを利用した非同期メッセージングにて実現されています。

チューニングの注意点

   最後に注意事項をあげておきます。パフォーマンス・チューニングを行う場合は、必ず達成する目標数値（レスポンスタイム、単位時間あたりの処理件数など）を先に決め、そして、実際に測定を行いながら作業を進めてください。

   ここに述べたようなことを闇雲に行ったといってパフォーマンスが向上する保証は何もなく、また、どのようにしたからパフォーマンスの向上になったか、というノウハウの蓄積にもなりません。このことはパフォーマンス・チューニングを行う上で基本的なことであり、かつ非常に重要なことです。

   実はまだまだチューニング手法として利用可能なアイデアやしくみが組み込まれているのですが、紙面の都合上今回はここまでとさせてください。

   次回は、JBossの固有機能について説明する予定です。