あなたのEJBシステム遅くないですか？：WebSphereサーバ・チューニング入門（5）（3/3 ページ）

» 2008年01月24日 00時00分公開

[上野憲一郎，日本アイ・ビー・エム]

（2）EJBコンテナのプール・サイズ

　アプリケーションごとにEJBインスタンスのプール・サイズを指定することができます。管理コンソールから、汎用JVM引数に以下のような指定を行います。

-Dcom.ibm.websphere.ejbcontainer.poolsize=<application_name>

      #<module_name>#<enterprisebean_name>=<minSize>,<maxSize>

＜application_name＞
EARファイル内のデプロイメント・ディスクリプタに設定されているJava EE（J2EE）アプリケーション名
＜module_name＞
EJBモジュールの.jarファイル名
＜bean_name＞
EJBモジュールのデプロイメント・ディスクリプタに指定されているJava EEエンタープライズ・ビーン名
＜minSize＞
プール中に保持されるBeanインスタンスの最小数
＜maxSize＞
プール中に保持されるBeanインスタンスの最大数。この値以上はインスタンスをプールに保持しない

　具体的な指定としては、以下のようになります。

-Dcom.ibm.websphere.ejbcontainer.poolsize=ivtApp

      #ivtEJB.jar#ivtEJBObject=125,1327

　「ivtApp」アプリケーション内の「ivtEJB.jar」ファイル中の「ivtEJBObject」ビーンに対して最小125、最大1327インスタンスをプールするという指定です。

　なお、プール・サイズの調整を行う際には、TPVを使用し、EJBインスタンスのプール状況を把握できます。

（3）EJBコンテナのプライマリー・キー・ミューテーション

　アプリケーション開発者や管理者は、CMP（Container-Managed Persistence）Beanあるいは、BMP（Bean-Managed Persistence） Beanによって利用されるプライマリー・キー・オブジェクトを、アプリケーションがどのように扱うかを理解しているでしょう。

　異なる視点として、EJBのランタイム環境であるWebSphere EJBコンテナは、内部データ構造を特定するためなどにEntity Beanのプライマリー・キーを使用し、パフォーマンス向上を図っています。

　通常、EJBコンテナは、アプリケーションがプライマリー・キーの更新を行った場合、それに対応するために（内部構造と整合性を合わせるために）、プライマリー・キー・オブジェクトをコピーしなければなりません（内部キャッシュに保持されるオブジェクトとアプリケーション内から使われるオブジェクトとの整合性保持のため）。

　Entity Beanが作成された後で、Entity Bean作成およびアクセスのために使用されるプライマリー・キーに対してアプリケーションが変更を行わない場合には、「noPrimaryKeyMutation」フラグを設定することによりプライマリー・キー・オブジェクトのコピーを省略でき、パフォーマンス向上が期待できます。

　管理コンソールから、汎用JVM引数に以下の指定を追加することにより設定します。

-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true

　このオプションがパフォーマンスに効果があるかどうかはアプリケーションに強く依存します。アプリケーションが、Enterprise Beanのプライマリー・キーにプリミティブ・オブジェクト・タイプを使用している場合には効果がないでしょう（オブジェクトは「immutable」であるため）。

　それに対して、アプリケーションが、複雑なプライマリー・キーを使用している場合には、パフォーマンス向上が期待できます。

【3】パーシステンス・マネージャのチューニング

　3つ目のチューニング対象コンポーネントは、パーシステンス（DBの永続化）・マネージャです。

　WASのパーシステンス・マネージャは、EJBコンテナの中の1つのコンポーネントで、「CMP」Entity BeanのデータをDBに永続するために使用されます。

　従いまして、以下のチューニング項目はCMPに対して有効です。パーシステンス・マネージャのチューニング項目としては、以下の3つなどがあります。

Deferred Insert on EJB Create
Batch Update on EJB Update
キャッシュ・チューニング

（1）Deferred Insert on EJB Create

　ejbCreate()メソッドの呼び出しによって、Entity Beanが作成された際に、パーシステンス・マネージャは即時に、プライマリー・キーのみの空の行をDBに挿入します（デフォルトの動き）。

　多くのアプリケーションは、Beanを作成した後、作成したBean（あるいは同じトランザクション中の異なるBean）のフィールドを更新します。そういったケースでは、トランザクションの最後までDBへの挿入を延期することにより、DBへのアクセス・トリップを1往復削減できます。

　つまり、新しく作成されたEJBへの操作のためのDBへのアクセスを2回（insert and update）から1回（insert）へ削減することになります。もちろん、データはDBに挿入されますし、整合性も保持されます。

　パフォーマンスへの効果は、アプリケーションに依存します。EJBアプリケーションが、「insert」を非常に多く実施している場合には、このオプションによるパフォーマンス向上が期待できます。

　このオプションは、管理コンソールから、汎用JVM引数に以下の指定を追加することにより設定できます。

-Dcom.ibm.ws.pm.deferredcreate=true

参考：EJB 2.1仕様の「10.5.3 Container's View」から抜粋

The container may create the representation of the entity in the database immediately, or it can defer it to a later time (for example to the time after the matching ejbPostCreate＜METHOD＞ has been called, or to the end of the transaction), depending on the caching strategy that it uses.

（2）Batch Update on EJB Update

　EJBアプリケーションが、1つのトランザクション内で複数のCMP Beanに対してアクセスする場合、CMP Beanに対して実施された操作とDBに対して発行される操作が対応します。つまり、複数の操作をCMP Beanに対して実施すると、それに対応した複数のDB操作が行われることになります。

　使用しているアプリケーションが、1つのトランザクション内で複数のCMP Beanに対して更新を行う場合で、かつ、使用しているDBシステムがバッチ更新処理をサポートしている場合には、バッチ更新オプションを設定することによりパフォーマンス向上が期待できます。これは、1つのトランザクション内の複数の更新処理をバッチ処理することにより、DBアクセスのためのラウンド・トリップを削減できるからです。

　このオプションは、管理コンソールから、汎用JVM引数に以下の指定を追加することにより設定できます。

-Dcom.ibm.ws.pm.batch=true

（3）パーシステンス・マネージャ・キャッシュ・チューニング

　パーシステンス・マネージャは、2つの異なるキャッシュの仕組みを持っていて、「Legacy Cache」および「Two-level Cache」と呼ばれています。デフォルト設定としては、「Legacy Cache」が使われます。「Two-level Cache」は性能改善が施されており、パフォーマンスの観点からは、「Two-level Cache」が推奨されています。

　このオプションは、管理コンソールから、汎用JVM引数に以下の指定を追加することにより設定できます。

-Dcom.ibm.ws.pm.useLegacyCache=false

【参考】EJBクライアントとEJBの配置（トポロジー）

　ここまでの話と少し視点が異なりますが、今回の最後のトピックとして、EJBクライアントとEJBの配置（トポロジー）について解説します。

　EJBを使用するケースで、特に多いシナリオは、EJBクライアントをWebコンテナ上で稼働し、EJBコンテナ上のEJBにアクセスするというものです。その場合に、以下の3通りのトポロジーが考えられます。

図9　EJBシステムのトポロジー

　以下の2つの点を考慮すると、トポロジー1がパフォーマンス性能としては有利です。

「参照による受け渡し（Pass by Reference）」によるパフォーマンスのメリット（ローカル・コピー不要、パラメータのシリアライズ不要）
EJBローカル・インターフェイスによるパフォーマンスのメリット（ローカル・コピー不要、パラメータのシリアライズ不要、ローカル・コールによるメソッド呼び出し）

　無条件で（特に強い理由なしで）トポロジー3を選択しているケースを見掛けることがありますが、パフォーマンス性能がシステム構築の重要なポイントである場合には、トポロジー1を選択肢として検討することをお勧めします。

次回はアプリケーションの設定を中心に

　さて、ここまでで今回は終了ですがいかがでしたでしょうか。今回は、WASのサーバ設定によるEJBパフォーマンス・チューニングの解説を行いました。次回は、アプリケーション設定（デプロイメント・ディスクリプタの設定）によるトランザクションを中心としたチューニングについて解説します。

＠IT関連記事

JBOSSでかんたんEJB
無償で使えるEJBサーバ「JBOSS」とEclipseを使って、簡単なEJBプログラミングを体験し、EJBを理解します。この連載で苦手意識を払拭！

AntとXDocletでEJB開発を効率化
[連載]現場に生かすJakarta Project(3)ファイルが多いために煩雑になりやすいEJB開発。AntとXDocletを使うと非常に効率よく開発ができ、その問題が解決できます
「Java Solution」フォーラム 2003/2/19

さよならJDBC？EJBの出番はこれから？
[特別企画] EJBはEJB2.0の登場でEJB1.1時代のパフォーマンスの問題を解決したといわれる。EJB2.0は、EJBに実用期をもたらしたのか？
EJB2.0のメリットを解説
「Java Solution」フォーラム 2002/12/25

J2EEの基礎
この講座では、これからサーバ・サイドJavaを学ぶ人のために、J2EEをWebとDBをつなぐミドルウェアという観点で捉えて説明していきます

樋口研究室スマートなサーバ・サイドJava
Javaとノーツの研究記事で人気の樋口研究室が＠ITにも参上。ベストなeビジネス・アプリケーションを実現するためのノウハウを、あなたの仕事にも生かしてみよう！

EJBの作成とデバッグ
[連載]初めてのWebアプリケーション・サーバ(最終回）
最終回は、いよいよEJBツールを使ってEJBを作成したあと、デバックまで行います
「Java Solution」フォーラム 2001/9/7

Webアプリケーションにおけるサーバ・サイドJavaの効果的な利用
EJB（Enterprise JavaBeans）はアプリケーション・サーバ上でのシステム構築に必要不可欠になりつつある。EJBの役割とアーキテクチャをわかりやすく解説する

プロフィール

日本アイ・ビー・エム東京基礎研究所　アドバイザリー・リサーチャー

上野憲一郎（うえのけんいちろう）
kenueno@jp.ibm.com

日本アイ・ビー・エムに入社後、システム・エンジニアとして10年ほど活動した後、米国IBMへ赴任。米国IBM Raleighソフトウェア開発研究所にて、WebSphere Application Server開発部門のパフォーマンス専門グループのメンバーとして活動。2003年に帰国後、IBM東京基礎研究所にて、XML、Web サービス、SOA関連技術の研究開発に従事。WebSphere Application Serverパフォーマンス専門家として、セミナーなどで講演も実施。

主な著書
「WebSphere V3.5 Handbook」（Prentice Hall）

主な訳書
「Webサービスプラットフォームアーキテクチャ」（エスアイビーアクセス）

「次回」へ

「WebSphereサーバ・チューニング入門」バックナンバー