10gリリース3（10.1.3.1.0）
B31836-02
 目次 |
 索引 |
| Oracle Application Server パフォーマンス・ガイド 10gリリース3（10.1.3.1.0） B31836-02 |
|
この章には、Oracle Application Serverの次の分野のパフォーマンス情報が含まれています。
Oracle TopLink（TopLink）には、アプリケーションのパフォーマンスを最適化するための機能があります。そのうち、重要な分野は次のとおりです。
ReportQueriesを使用して、読み込んでオブジェクトとしてキャッシュする必要があるのは、変更可能か、またはリクエスト間で共有可能なオブジェクトのみであることを確認します。
UnitOfWorkを使用してトランザクション・スコープを最小化し、それによってコミット・サイクルを最小化する方法を理解しておいてください。
TopLinkのドキュメントには、これらの重要なTopLinkのパフォーマンス分野に関する情報が含まれています。TopLinkのパフォーマンスを最適化するためのアプリケーションをチューニングする方法の詳細は、ドキュメントの該当する章を参照してください。
この項では、JTAのパフォーマンス・オプションについて説明します。この項には、次の項目が含まれています。
構成オプションを使用することで、2フェーズ・コミット・ロギングのタイプとレベルを制御できます。構成オプションを変更するには、transaction-manager.xmlファイルを変更するか、またはJTAリソースのMBeanを使用します。このMBeanは、Application Server Controlコンソールの「トランザクション・マネージャ」ページで利用できます。2フェーズ・コミット・ロギングを構成する場合は、2フェーズ・コミット・ロギングをオフにしたときのトランザクションへの波及効果を認識しておく必要があります。
表4-1に、2フェーズ・コミット・ロギングの構成オプションを示します。これらのオプションは、transaction-manager.xmlで設定するか、またはJTAリソースのMBeanを使用して設定できます。
表4-2で、ファイル・ストア・ロギングのパフォーマンス設定について説明します。これらの設定はtransaction-manager.xmlで指定するか、またはJTAリソースのMBeanを使用して指定できます。2フェーズ・コミット・トランザクションの最大同時実行数が256より少ない場合は、デフォルト設定が適しています。
2フェーズ・コミット・トランザクションの最大同時実行数を判定するには、JTAResourceメトリック表のTwoPhaseCommitCompletion.maxActiveメトリックを使用します。
この項には、次の項目が含まれています。
一般的に、XAに準拠していないデータソースは、XAデータソースより高速です。XAに準拠した完全な2フェーズ・コミットが必要な場合は、XAデータソースを使用する必要があります。
トランザクションのロギングがnoneに設定されている場合は、XA準拠または非準拠のリソースを、グローバル・トランザクションでいくつでも確保できます。ただしこの場合、ACIDの保証にもリカバリにも対応しません。
トランザクションのロギングが有効になっている場合は、グローバル・トランザクションに組み込むリソースはXAに準拠していることが必要です。最終リソース・コミット機能を使用すると、XAに準拠していない単一のリソースを、XAトランザクションに組み込むことができます。
最終リソース・コミットは、XAに準拠していないリソースをグローバル・トランザクションに組み込めるだけでなく、パフォーマンスの最適化を図るために使用することもできます。XA対応リソースを非XAリソースとして確保して最終リソース・コミットを使用すると、そのリソースがXAロギングを実行する必要がないため、パフォーマンスが向上します。また、そのリソースはインダウト状態、つまり準備状態には決してならないため、リソースのロックが発生しません。最終リソース・コミットは、パフォーマンスの最適化を図るために使用できますが、そのかわり正確性は保証されなくなります。
単一のリソースへのアクセスにアプリケーションが複数のデータソースを使用すると、（XAトランザクションを使った）2フェーズ・コミット操作が、意図せずに使用される可能性があります。一部のケースでは、構成を変更することでパフォーマンスが向上することがあります。この構成変更により、OC4Jは2フェーズ・コミットでなく1フェーズ・コミットを使用するようになります。
次のメトリックを使用すると、1フェーズ・コミット数と2フェーズ・コミット数、およびリソースの確保を行わないグローバル・トランザクションの件数を確認できます。
/oc4j/JTA/SinglePhaseCommitCompletion.completed /oc4j/JTA/TwoPhaseCommitCompletion.completed /oc4j/JTA/AverageCommitTime.completed
同じグローバル・トランザクション内に複数のデータソースが存在する場合は必ず、それらのデータソースが実際には同じデータベースを指していたとしても、XAの2フェーズ・コミット・トランザクションが使用されます。アプリケーションで使用するデータソースが単一のデータベースおよびスキーマにデプロイされている場合は、単一のデータソースを使用するようにアプリケーションを再構成することができます。これにより、2フェーズ・コミットが1フェーズ・コミットに変更され、パフォーマンスが向上します。
このように、表など従来型のデータベース・リソースを使用し、リソースが同じデータベースに存在している場合にOJMSを使用するトランザクション型アプリケーションは、リソースごとに単一のデータソースを指定することにより、一部の2フェーズ・コミットを回避できます。この変更によってパフォーマンスが向上しますが、この場合、OJMSデータソースの構成が、表へのアクセスに対して指定された構成と一致している必要があります。
JTAリソースを監視する際には、エラーによってパフォーマンス上の問題が発生する可能性があることに注意してください。JTAエラーがあるかどうかを調べるには、JTAResourceメトリック表のメトリックを使用して、ロールバックと例外の件数に0より大きい数値がないかを調べます。たとえば、RollbackExceptionCount、RolledbackCount、SystemExceptionCountの各メトリックの値を調べます。
また、一部のパフォーマンス上の問題からJTAエラーが発生することもあります。たとえば、パフォーマンスが悪い場合に、タイムアウト・エラーが発生することがあります。この場合は、メトリックRolledbackDueToTimedOutCountの値を調べます。
この項では、次の項目について説明します。
この項では、orion-ejb-jar.xml構成ファイルで指定され、メッセージドリブンBean（MDB）に適用される、パフォーマンスに関連する重要なEJB構成プロパティのいくつかについて説明します。内容は次のとおりです。
MDBのキューにメッセージを送信する多数の同時ユーザーがいる場合やonMessageメソッドで大量の処理が発生する場合、MDBに対してJMSコネクタのレシーバ・スレッド数を設定すると、パフォーマンスを向上させることができます。たとえば、onMessageメソッドに別のEJBをコールするコードが含まれていて、他のメッセージの処理中にEJB処理が同時に発生する場合、JMSコネクタのレシーバ・スレッドを1より大きい値に設定するとパフォーマンスが向上します。基礎となるJMSコネクタおよび特定のMDBによっては、JMSコネクタのReceiverThreads構成プロパティの値を増やすと、パフォーマンスが大幅に向上するアプリケーションもあります。
たとえば、キューに100個のメッセージが含まれていて、ReceiverThreadsがデフォルト値の1に設定されている場合、メッセージは順番に1つのMDBのレシーバ・スレッド・プロセスによってのみ処理されます。ReceiverThreadsを5に設定すると、最大で5個のMDBインスタンスがキューからメッセージを取得でき、メッセージをパラレル処理できることが指定されます。この例では、OC4Jはメッセージのデキューと処理に最大5個のMDBスレッドを使用するので、100個のメッセージの処理の完了に必要な合計時間は短くなります。
JMSコネクタのReceiverThreadsの値を1より大きい値に設定すると、MDBの複数のインスタンスによって、キューのメッセージを同時に処理できるようになります。ただし、この場合、パフォーマンスの向上は、アプリケーションおよび指定したスレッドの数によって異なります。指定した値が大きすぎると、リソースの競合によってパフォーマンスが低下することがあります。
メッセージを順番に処理する必要がある場合は、値が1に設定されたJMSコネクタのReceiverThreadsを使用します。1より大きい値を設定したReceiverThreadsを使用した場合、メッセージはキューから逐次削除されますが、MDBでは複数のスレッドでメッセージが処理されるのでメッセージを処理する順序は保証されません。
OC4Jは、JMSコネクタのレシーバ・スレッドとして使用されるスレッドを作業マネージャのスレッド・プール（Application Server Controlコンソールおよびserver.xmlでjcaスレッド・プールとして示される）から割り当てます。JMSコネクタのレシーバ・スレッド数は、作業マネージャのスレッド・プールで、jcaスレッド・プールのmaxパラメータを使用して制限できます。また、minの値を使用して、作業マネージャのスレッド・プールの利用可能なスレッドの初期数を設定することもできます。
JMSコネクタのReceiverThreadsの値を設定するときには、次の構成オプションを調整する必要があります。
thread-poolのmaxスレッドに、次のいずれかを加算したものになります。
ReceiverTheadsとアクティブなMDB Beanインスタンスの数は、1対1の関係になります。MDBの初期処理時間が長くなる可能性がある場合は、MDBのmin-instancesを、JMSコネクタの目的のReceiverTheadsと一致するように設定して、それらのインスタンスが起動時に初期化されるようにします。 また、MDB構成のmin-instancesの値は、MDBごとに設定されたJMSコネクタのReceiverThreadsより大きな値にしないように構成してください。
目的のインスタンス数を維持するには、アイドル中にMDBインスタンスが削除されないように、pool-cache-timoutを十分な長さの値に設定します。
MDBでデータベース接続が必要な場合は、JMSコネクタのReceiverThreadsの数によって、必要なデータベース接続の数も乗算されます。たとえば、あるMDBで5つのデータベース接続が同時に使用され、アクティブなMDBインスタンスが5つある場合、要求されるデータベース同時接続数は25になります。このように、データソースmax-connectionsの件数の計算には、JMSコネクタのReceiverThreadsの数を組み込む必要があります。
MDBは、ステートレスで、複数の起動にわたって特定のクライアントの状態を保持することはありません。ただし、クライアント関連以外の状態については、MDBインスタンスは、複数のクライアント・メッセージの処理の間、状態を保持できます。たとえば、ルックアップの状態を保持できます。さらに、EJBへの参照など、onMessageの複数の起動にわたってキャッシュする必要があるその他の状態情報は、ejbCreateメソッドで初期化されてキャッシュされ、MDBのパフォーマンスが最適になります。
アイドル状態のMDBオブジェクトがプールから削除され、必要に応じて再割当てされる場合は、ejbRemoveメソッドで、状態を忘れずに破棄してください。
MDBでOracleAS JMSがメッセージ・プロバイダとして使用される場合、Oracle Application Serverパフォーマンス監視ツールからDMSメッセージ関連のメトリックを使用できます。
たとえば、OracleAS JMS JMSStoreStatsメトリック表には、MDBによって使用されるキューに対応する宛先の情報が含まれています。
destination.value: name messageDequeued.count: x ops messageEnqueued.count: x ops messageCount.value: n
これらのメトリックには、宛先名、エンキューされた合計メッセージ数、デキューされた合計メッセージ数、およびキュー内の現在の合計数が表示されます。
また、MDBのonMessageメトリックを調べて、onMessageの時間が予想どおりの長さになっているかを確認したり、maxActiveメトリックを使用して、同時実行されるレシーバ・スレッドの合計数が予想どおりの数になっているかを確認することもできます。
client.active: 1 threads client.avg: 112 msecs client.completed: 4 ops client.maxActive: 1 threads client.maxTime: 70 msecs client.minTime: 130 msecs client.time: 121 msecs
Application Server Controlコンソールには、すべてのMDBと個々のMDBのパフォーマンスに関する情報が表示されます。
MDBのサマリー情報にアクセスするには、次の手順を実行します。
Active Connections Messages Waiting for Read Messages Waiting for Commit Messages Enqueued per Second Messages Dequeued per Second Messages Paged In per Second Messages Paged Out per Second Messages Committed Since Startup Messages Rolled Back Since Startup Messages Expired Since Startup
個々のMDBの情報にアクセスにするには、Application Server Controlコンソールのパフォーマンス領域を使用します。
Messages Dequeued Messages Rolled Back Average Message Processing Time (seconds) Number of Available Instances Number of Used Instances
この項では、CMPを使用するエンティティBeanで利用できるいくつかのパフォーマンス・オプションについて説明します。次の項目が含まれます。
この項では、効率的なSQL文とSQL問合せの使用について説明します。表4-3と表4-4に、SQL文およびSQL問合せに関連するチューニング・パラメータとパフォーマンス推奨事項を示します。
表4-4に、パフォーマンスのチューニングのためのCMRパラメータを示します。
表4-5に、キャッシュ構成オプションを示します。
| チューニング・パラメータ | 説明 | パフォーマンス上の注意 |
|---|---|---|
|
オブジェクト・キャッシュ |
TopLinkセッションには、オブジェクト・キャッシュが用意されています。TopLink永続性マネージャを使用するCMP 2.1アプリケーションがTopLinkセッションを作成し、そのセッションはデフォルトでこのキャッシュを使用します。セッション・キャッシュと呼ばれるこのキャッシュには、データベースとの間で読み書きされたオブジェクトの情報が格納されます。セッション・キャッシュはTopLinkアプリケーションのパフォーマンスを向上させるための重要な要素の1つです。通常、サーバー・セッションのオブジェクト・キャッシュは、そのセッションから取得されたすべてのクライアント・セッションで共有されます。分離セッションは、共有オブジェクト・キャッシュから分離された固有のセッション・キャッシュを備えています。 関連項目: 『Oracle TopLink開発者ガイド』の、オブジェクト・キャッシュに関する項 |
即時問合せに対しては無効にします（分離キャッシュを使用）。 |
|
問合せ結果セット・キャッシュ |
TopLinkでは、TopLinkのオブジェクト・キャッシュに加えて、問合せキャッシュもサポートしています。
関連項目: 『Oracle TopLink開発者ガイド』の、問合せ結果のセッション・キャッシュへのキャッシングに関する項 |
主キー以外のキーで頻繁に実行される問合せのうち、結果セットがめったに変わらないものに使用します。 キャッシュ検証タイムアウトとともに使用し、必要に応じてリフレッシュします。 |
|
キャッシュ・サイズ |
デフォルト値: 関連項目: 『Oracle TopLink開発者ガイド』の、キャッシュおよびアイデンティティ・マップの構成のガイドラインに関する項 |
キャッシュ・サイズは、1つのトランザクション内で参照される（同タイプの）オブジェクトの最大数を格納できる大きさに設定します。 |
|
ロック |
表4-6に示すロック方針がサポートされています。 関連項目: 『Oracle TopLink開発者ガイド』の、ロック方針の構成に関する項と記述子およびロックの概要に関する項 |
|
|
キャッシュ使用 |
キャッシュ使用一致を使用すると、セッション・キャッシュはチェックされません。全読取りの場合、まずデータデースをチェックし、その後、作業ユニットの変更と新規オブジェクトおよび削除されたオブジェクトに結果を一致させます。オブジェクト読取りの場合、まず作業ユニットの変更と新規オブジェクトをチェックして一致するオブジェクトがないかどうかを確認し、その後、データベースをチェックして、変更と削除されたオブジェクトに結果を一致させます。
一致機能は、
デフォルト: |
コミットされていないデータをトランザクションに読み取らせる必要がない場合、特に読取り専用操作では、各記述子、および不要な場合は問合せレベルで、キャッシュ使用一致をオフにします。 |
|
分離 |
TopLinkを使用するCMPアプリケーションには、特定のデータベース・トランザクションの分離レベルを単独で設定するチューニング・パラメータはありません。一般的なCMPアプリケーションでは、データベース・トランザクションの分離レベルが適用されるとき、また特定のデータベース・トランザクションを分離できる程度には、次のような様々な要素が影響します。 関連項目: 『Oracle TopLink開発者ガイド』の、データベース・トランザクションの分離レベルに関する項 |
|
|
キャッシュのリフレッシュ |
デフォルトでは、TopLinkはデータソースから読み取ったオブジェクトをキャッシュします。これらのオブジェクトに対する後続の問合せでは、キャッシュへのアクセスが行われます。その結果、データソースへのアクセスが減り、オブジェクトとその関係を再構築するコストが不要になるため、パフォーマンスが向上します。全読取り問合せなどの問合せでデータソースにアクセスした場合も、返されたレコードに対応するオブジェクトがキャッシュに存在すれば、キャッシュ内のオブジェクトが使用されます。このデフォルトのキャッシング方針は、失効したデータをアプリケーションにもたらす場合があります。
リフレッシュは、記述子レベル（ 失効したデータや競合するデータがデータベースにコミットされないようにするには、適切なロック方針を使用するしか方法がありません。キャッシュでのデータのリフレッシュに関して、考慮すべきケースがいくつかあります。これらのケースはいずれも、パフォーマンスに影響を及ぼします。
関連項目: 『Oracle TopLink開発者ガイド』の、キャッシュのリフレッシュの構成に関する項 |
記述子レベルでのキャッシュのリフレッシュはできるだけ避け、かわりに次の構成を検討してください。
|
|
注意 デフォルトでは、TopLinkは、アプリケーションがそのアプリケーションで使用しているデータに排他アクセスしている（つまり、TopLink以外にデータを変更する外部アプリケーションは存在しない）と想定しています。アプリケーションがデータに排他アクセスしていない場合は、表4-5のデフォルト設定を一部変更する必要があります。 |
TopLink永続性マネージャおよびキャッシュとともに使用されるCMP2.1のデフォルト設定は、ロックなし、キャッシュのリフレッシュなし、キャッシュ使用一致なしです。排他アクセスができないときに、アプリケーションがキャッシュから失効データを読み取らないようにし、必要なデータ整合性レベルを維持するには、分離レベルに関連するこれらの設定や他の設定を適切に構成する必要があります。
表4-6に示すロック・モードを、TopLinkのキャッシュ使用オプションおよび問合せリフレッシュ・オプションとともに使用すると、CMPを使用するEJBエンティティBeanのデータ整合性が保証されます。組合せは機能およびパフォーマンスの両方に関連していますが、通常はパフォーマンスよりも最新データとデータ整合性のための機能上の要件を優先して、これらのオプションの設定を決定します。
EJBメソッドの実行に著しく時間がかかっていないかを確認するには、oc4j_ejb_methodというDMSメトリック表のタイプとメトリックwrapper.avgまたはclient.avgをチェックします（メソッドのなかには、完了までに長時間かかることが予想されるものもあるので、異常に大きな値がないかを調べます）。たとえば、ejbCreate、create、findAllの各メソッドや、アプリケーション固有のEJBメソッドのメトリック値をチェックします。
また次の手順に従って、Application Server Controlコンソールに表示されるメトリックをチェックすることで、レスポンス時間やトランザクション/秒が時間の経過とともにどのように推移しているかを確認できます。
また、CMP TopLinkのメトリックを参照して、CMPのパフォーマンスに関する追加情報を確認することもできます。
|
関連項目
|
|
 Copyright © 2001, 2008, Oracle. All Rights Reserved. |
|